Monday, December 19, 2005


Just because they said "DirectXmas" on their frontpage, I must link to remind myself of:

C# Static Classes

Static classes are meant to replace the design pattern of creating a sealed class with a private constructor that contains only static methods. A static class is denoted by placing the static modifier on the class declaration. For example: public sealed class Environment
// Keep class from being created
private Environment() { }
can now be written as: public static sealed class Environment
The benefit of using a static class instead of the design pattern above is that the compiler can now report an error if any instance methods are accidentally declared.

(from link)

Saturday, December 17, 2005

C# Using Statement

C#, though the .NET Framework common language runtime (CLR) automatically releases the memory used to store objects that are no longer required. The release of memory is non-deterministic; memory is released whenever the CLR decides to perform garbage collection. However, it is usually best to release limited resources such as file handles and network connections as quickly as possible.

The using statement allows the programmer to specify when objects that use resources should release them. The object provided to the using statement must implement the IDisposable interface. This interface provides the Dispose method, which should release the object's resources.

(from MSDN VS20005 documentation)

Windows ISO Mounting Tool

Wednesday, December 14, 2005

Erasures in Java 1.5

..., the generics implementation uses a technique known as erasure. The easiest way to understand erasure is to think of the compiler as performing two distinct tasks. First, it does type checking at compile time using all the type information it has (including the type parameters). Then it transforms the code, using a set of rules that remove all of the type parameters (e.g. all of the parameterized types are mapped to raw types), and inserts a set of casting operations. The complete list of transformations is beyond the scope of this article. However, to give you an idea of what erasure does, here are some of the rules:

  • If a class doesn't use type parameters in its definition, erasure doesn't change the class definition.
  • Parameterized types "drop" their type parameters.
  • Every type parameter is mapped to the appropriate bound. By this, I mean: the type parameter is erased and replaced with the strongest type the compiler can reasonably assert. Thus, in the case of , T is mapped to Object. In the case of , T is mapped to Rentable, and so on.
  • Casts are inserted wherever necessary, to ensure that the code compiles.
(from link)

Structs vs. Classes in C#

From the MSDN Structs Tutorial:

Structs vs. Classes
Structs may seem similar to classes, but there are important differences that you should be aware of. First of all, classes are reference types and structs are value types. By using structs, you can create objects that behave like the built-in types and enjoy their benefits as well.

Heap or Stack?
When you call the New operator on a class, it will be allocated on the heap. However, when you instantiate a struct, it gets created on the stack. This will yield performance gains. Also, you will not be dealing with references to an instance of a struct as you would with classes. You will be working directly with the struct instance. Because of this, when passing a struct to a method, it's passed by value instead of as a reference.

Monday, December 12, 2005

LoudNetworks in the Hizouse

The LoudNetworks team in full force:

Phase 1: Design and implement (efficient) reliable communication between two PCs using a microphone and speaker. CHECK
Phase 2: Design and implement robust ad hoc routing between a set of PCs using sound as their only means of communication. CHECK
Phase 3: Design and implement (efficient, fair, etc.) resource control (that is, sound control) among a set of PCs using sound as their only means of communication. CHECK

Understanding C# Timers

All of this information is taken from VS2005 RC2 MSDN Documentation unless otherwise specified; unfortunately information about Timers is littered about the docs and not all in one place. So, in trying to make sense of it all, I made this compilation:

There are three timer controls in Visual Studio and the .NET Framework — the server-based timer you can see on the Components tab of the Toolbox, the standard Windows-based timer you can see on the Windows Forms tab of the Toolbox, and the thread timer that is only available programmatically.
  1. The Windows-based timer is optimized for use in Windows Forms applications.
  2. The server-based timer is an update of the traditional timer that has been optimized to run in a server environment.
  3. The thread timer is a simple, lightweight timer that uses callback methods instead of events and is served by thread-pool threads.

There are two types of threads in Win32 architecture: UI threads, and worker threads. UI threads sit idle most of the time and wait for messages to arrive in their message loops. Once they receive a message, they handle it and then wait for the next message to arrive. Alternatively, worker threads are used to perform background processing and do not use message loops. Both the Windows timer and the server-based timer run using an Interval property. The interval of the thread timer is set in the Timer constructor. The timers are designed for different purposes, as evidenced by their handling of threads:

  • The Windows timer is designed for a single-threaded environment where UI threads are used to perform processing. The accuracy of Windows timers is limited to 55 milliseconds. These traditional timers require that the user code have a UI message pump available and always operate from the same thread, or marshal the call onto another thread. For a COM component, this would be detrimental to performance.
  • The server-based timer is designed for use with worker threads in a multi-threaded environment. Because they use a different architecture, server-based timers have the potential to be much more accurate than Windows timers. Server timers can move among threads to handle the raised events.
  • The thread timer is useful in scenarios where messages are not pumped on the thread. For example, the Windows-based timer relies on operating-system timer support, and if you are not pumping messages on the thread, the event associated with your timer will not occur. The thread timer is more useful in this case.

Windows Form Timer
This class wraps the counters we had in Win32 based on Windows messages. Use this class only if you do not plan to develop a multithreaded application. The Windows Forms Timer component has an Interval property that specifies the number of milliseconds that pass between one timer event and the next. Unless the component is disabled, a timer continues to receive the Tick event at roughly equal intervals of time. This component is designed for a Windows Forms environment. If you need a timer that is suitable for a server environment, see Introduction to Server-Based Timers.

The Interval Property
The Interval property has a few limitations to consider when you are programming a Timer component:

  • If your application or another application is making heavy demands on the system — such as long loops, intensive calculations, or drive, network, or port access — your application may not get timer events as often as the Interval property specifies.
  • The interval can be between 1 and 64,767, inclusive, which means that even the longest interval will not be much longer than one minute (about 64.8 seconds).
  • The interval is not guaranteed to elapse exactly on time. To ensure accuracy, the timer should check the system clock as needed, rather than try to keep track of accumulated time internally.
  • The system generates 18 clock ticks per second — so even though the Interval property is measured in milliseconds, the true precision of an interval is no more than one-eighteenth of a second.

Thread safety: Any public static members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Server-Based Timers (System.Timers)
The Timer component is a server-based timer, which allows you to specify a recurring interval at which the Elapsed event is raised in your application. You can then handle this event to provide regular processing. For example, suppose you have a critical server that must be kept running 24 hours a day, 7 days a week. You could create a service that uses a Timer to periodically check the server and ensure that the system is up and running. If the system is not responding, the service could attempt to restart the server or notify an administrator. The server-based Timer is designed for use with worker threads in a multithreaded environment.

Server timers can move among threads to handle the raised Elapsed event, resulting in more accuracy than Windows timers in raising the event on time. For more information on server-based timers, see Introduction to Server-Based Timers.

Key Programming Elements of Server-Based Timers
The Timer component raises an event called Elapsed. You can create handlers for this event to perform whatever processing needs to occur. Some of the more important properties and methods of a Timer component include the following:

  • The Interval property is used to set the time span, in milliseconds, at which events should be raised. For example, an interval of 1000 will raise an event once a second.
  • The AutoReset property determines whether the timer continues raising events after the given interval elapses. If set to true, the timer continues to recount the interval and raise events. If false, it raises one event after the interval elapses and then stops.
  • The Start method sets the timer's Enabled property to true, which allows the timer to begin raising events. If the timer is already enabled, calling the Start method resets the timer.
  • The Stop method sets the timer's Enabled property to false, preventing the timer from raising any more events.

Thread safety: any public static members of this type are safe for multithreaded operations. Any instance members are not guaranteed to be thread safe.

Thread-timer (System.Threading.Timer)
Use a TimerCallback delegate to specify the method you want the Timer to execute. The timer delegate is specified when the timer is constructed, and cannot be changed. The method does not execute on the thread that created the timer; it executes on a ThreadPool thread supplied by the system. The callback method executed by the timer should be reentrant, because it is called on ThreadPool threads. The callback can be executed simultaneously on two thread pool threads if the timer interval is less than the time required to execute the callback, or if all thread pool threads are in use and the callback is queued multiple times.

When you create a timer, you can specify an amount of time to wait before the first execution of the method (due time), and an amount of time to wait between subsequent executions (period). You can change these values, or disable the timer, using the Change method.

As long as you are using a Timer, you must keep a reference to it. As with any managed object, a Timer is subject to garbage collection when there are no references to it. The fact that a Timer is still active does not prevent it from being collected.

Note: System.Threading.Timer is a simple, lightweight timer that uses callback methods and is served by threadpool threads. You might also consider System.Windows.Forms.Timer for use with Windows forms, and System.Timers.Timer for server-based timer functionality. These timers use events and have additional features.

Thread safety: This type is safe for multithreaded operations.

Other Timers
1. timeGetTime() : This Windows.DLL call can give you up to 1 microsecond of accuracy on some operating systems; however it can be up to 5 microseconds on Windows NT.
2. System.Tickcount (Environment.TickCount): Gets the number of milliseconds elapsed since the system started.
3. DateTime.Ticks: The value of this property represents the number of 100-nanosecond intervals that have elapsed since 12:00:00 midnight, January 1, 0001.
4. QueryPerformanceCounter: often used in C++ Windows games. Provides a high resolution timer of less than 1 microsecond. Not exposed in managed code, so you would have to write a wrapper for it.

Programming the Thread Pool in the .NET Framework
System.Timers Namespace
Introduction to Server-Based Timers
Timer Programming Architecture
Introduction to the Windows Forms Timer Component

Other C# Timer Resources
Comparing the Timer Classes in the .NET Framework Class Library (added 12/15/05 5:37PM) (added 12/20/05 2:20)
The mvps link is very revealing; it discusses timers in the context of high performance games and evaluates them via benchmarking.

Sunday, December 11, 2005

Redick vs. Morrison

My officemate saw Adam Morrison of Gonzaga sink a last second three-point shot over two defenders with 2.5 seconds left yesterday at Key Arena (where the Seattle Supersonics play). We also watched Morrison dominate the game vs. U. of Washington last week (43 points, which ties his career high) -- Morrison is a spectacle, his shot is perfect and he always seems to be in the right place to get a much-needed steal or pick up an offensive rebound. I also observed that he tends to "power dribble" immediately after receiving a pass, which is particularly difficult to guard given that he is 6'9".

J. J. Redick of Duke also had an amazing performance yesterday, scoring a career-high 41 points vs. the #2 team in the country (Texas). He shot 9/16 from the three-point line.

Katz compares the two on espn for a preliminary investigation of NCAA player of the year.


Friday, December 09, 2005

Painting Techniques in .NET

Nash a Professional Soccer Player

You cannot escape the "grass-is-always-greener" syndrome:

"'How good are you?', I asked him after his team won. 'I guess I could have played professionally,' he said. 'If I’d focused on it. Sometimes I wish I had. But that’s probably just a grass-is-always-greener kind of thing.' " [Steve Nash talking about playing soccer professionally]

(from link)

Sunday, December 04, 2005

CFP: mobilehci

The 8th International Conference on
Human-Computer Interaction with Mobile Devices and Services
Dates: 12-15 September, 2006
Location: Espoo, Finland
* Papers, Workshops and Tutorials: 1 March 2006
* Short Papers, Posters, Demos, Panels, Industry Cases: 7 May 2006