[concurrency-interest] Re: Fun with AbstractQueuedSynchronizers (Doug Lea)
Sun, 04 Jan 2004 15:41:03 -0500
>From: Doug Lea <email@example.com>
>Date: Tue, 30 Dec 2003 11:55:24 -0500
>Subject: [concurrency-interest] Fun with AbstractQueuedSynchronizers
>We've been fine-tuning AbstractQueuedSynchronizer and checking out
>whether it serves as a useful basis for various custom sync utilities
>and locks that we don't otherwise provide. An example of one of these
>is below. I couldn't figure out what to do with it after making it,
>so decided to post it here.
>It's an analog of a WIN32 "Consumable" Event, that can be done in only
>a few lines of implementation code, plus declarations and relays to
>tie these to public methods. (We once contemplated providing
>something like this class in j.u.c. The reason we don't is that there
>are only rare occasions when you'd prefer to use this over a
>Semaphore, which is normally a better choice because it doen't "lose"
I think these will be handy for state-focused systems (as opposed to
event-focused, where Semaphore is a better fit). These systems tend to
have something akin to a dog that can carry more than one newspaper.
An (possibly real-world) example: I've got one system that produces new
jobs, and another that consumes all the available jobs as a batch. The
producer and consumer share a ConsumedIndicator. The producer set()s it
whenever it produces a job. The consumer await()s whenever it's not
A "nice-to-have" class. If I'm the only one who likes it, maybe save it
for the next dluc as an example of how to use Sync.
Why "set()" and "await()"? To avoid confusion with "wait()", "notify()"
and "notifyAll()" ?