The ability to interrupt a thread and change what it's doing is a much different requirement and a
far more difficult one to achieve. If you are thinking along these lines, reconsider your objectives
very carefully! Why do you want to interrupt this particular thread? Could you get your work done
by (1) polling from this thread, (2) waiting for this thread to complete its present task and then
looking at a queue, or (3) simply creating a new thread to execute the task at hand? There is
probably a simpler means of doing what you want. Find it.
Win32 I/O Completion Ports
An I/O completion port is Win32's answer to the producer/ consumer problem. You create a
completion port with a file handle and then have a number of threads waiting on that completion
port. When a packet arrives on that handle, one of the waiting threads is awakened and given the
packet to work on. Upon completion, the thread sends any reply it needs to send and goes back to
wait on the port again. Windows NT hackers love these things.
Communicating via Streams
On occasion you will see discussions of communicating between threads via streams, pipes,
sockets, or some other higher level of communication. There are valid reasons for doing this, but
most of those reasons boil down to "to interface with existing code." If you're working with an
interface that someone else defined, OK. Do it that way. Otherwise, forget it! What do you think
you're doing? How often do threads want to exchange bytes? Practically never. They want to
exchange objects. Even when they're using strings, what they want to communicate is the string,
not the characters that make it up. So pass a string object.
Consider what a stream does. It supplies characters to a thread. If there are no characters in the
stream, the caller blocks. When another thread writes into the stream, the first thread wakes up,
removes the new characters, and starts over again. It's a producer/ consumer model restricting the
queue to bytes. And which one do you think is faster?
So you can communicate via streams, but... Don't do that.
Volatile
This keyword in C is used to indicate to the compiler that the variable in question changes
independent of the local code. Hence, the compiler is not allowed to optimize away loads or stores.
Indeed, loads must come from main memory, not be filled from cache. Stores should be expedited
around the store buffer. The idea here is that memory-mapped I/O uses memory addresses as I/O
registers and every read or write is meaningful. This is completely orthogonal to threads. Do not
use volatile with threads, thinking that it will solve any threading problem. You won't like the
results.
The Java spec says that volatile can be used instead of locking. It's right but misleading. Use
Performance
Condition Variables vs. wait/notify
Search WWH :
