Yeah. If I know that I'm going to hit shared services that aren't
purely stateless, then I will tend to use a worker that spawns a
thread, which can be polled from time to time. I wrote a nice little
wrapper infrastructure for this, so I basically just override the "do"
method and then the calling code just creates and starts one, then
periodically checks it. Very convenient, and now that I have a core-
duo, I can actually properly ensure that my tests test for race
conditions the correct way. (I've had so many tests that worked
because of a deterministic ordering on a single processor, but failed
in production on a multi-processor system.... aaaaargh)
You're right, though. The concurrency API is nice, and I use it
frequently. And thread creation and destruction is substantially
cheaper these days too - especially on Solaris, but really on most
platforms. Hooray for progress.
Christian.
On 20-Nov-07, at 7:47 PM, Howard Lewis Ship wrote:
The good news is that the synchronized keyword is getting really cheap
so code that gets distorted trying to avoid synchronized should just
code it up simply. Then there's the 1.5 concurrency support, which is
fantastic. Brian Goetz has talked about an arms race between the VM
guys and the concurrency guys to try and shave nanoseconds off this
stuff.
The pain comes when a chunk of code enters a synchronized block and
doesn't immediately return, when it calls other objects that may have
thier own synchronized blocks and you can hit a deadlock that way all
too easily.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
