[concurrency-interest] Re: Fun with AbstractQueuedSynchronizers (Doug Lea)

David Walend david@walend.net
Sun, 04 Jan 2004 15:41:03 -0500

concurrency-interest-request@cs.oswego.edu wrote:

>From: Doug Lea <dl@cs.oswego.edu>
>Date: Tue, 30 Dec 2003 11:55:24 -0500
>To: concurrency-interest@altair.cs.oswego.edu
>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 
doing jobs.

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()" ?



David Walend