
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Storing Thread-Specific Data Privately
|
1037
Discussion
One item to be aware of when using System.Threading.Timers and TimerCallbacks is
that they are serviced from the
ThreadPool. This means that if you have other work
being farmed out to the
ThreadPool in your application, it could be contending with
the
Timer callbacks for an available worker thread. The basic timer is enough to serve
the earlier scenarios, but if you are doing UI work and want to use timers, you
should investigate the
System.Windows.Forms.Timer class. If you are doing server
work, you might also want to look at
System.Timers.Timer as well. Both of these
classes add events for when the timers are disposed and when the timer “ticks”; they
also add properties that expose the settings.
See Also
See the “System.Threading.Timer Class,” “TimerCallback Delegate,” “System.Windows.
Forms.Timer Class,” and “System.Timers.Timer” topics in the MSDN documentation.
18.9 Storing Thread-Specific Data Privately
Problem
You want to store thread-specific data discovered at runtime. This data should be
accessible only to code running within that thread.
Solution
Use the AllocateDataSlot, AllocateNamedDataSlot,orGetNamedDataSlot method on
the
Thread class to reserve a thread local storage (TLS) slot. Using TLS, a large object
can be stored in a