develooper Front page | perl.perl5.porters | Postings from November 2003

Re: [PATCH] cond_wait() and arbitrary lock variables

Thread Previous
From:
Mike Pomraning
Date:
November 25, 2003 08:50
Subject:
Re: [PATCH] cond_wait() and arbitrary lock variables
Message ID:
Pine.LNX.4.58.0311242152460.1024@localhost.localdomain
On Mon, 24 Nov 2003, Elizabeth Mattijsen wrote:

> Could you elaborate?  How would this be different from using nested
> locks?  Or is this a quicker way to do that?

I imagine a shared $color object with some threads awaiting state "red", some
"green", and some "blue".  If $color uses a single cond+lock variable, then
some waiters will be woken up needlessly upon a color change.

If $color uses one lock for the color change and three distinct cond+lock vars
for the various states, then you have awkward and non-atomic nested
_un_locking concerns:  lock $color, inspect it, and cond_wait for "red",
making sure that you've somehow unlocked both $color and the separate
cond+lock var ($color->{_red}?).

Less contrivedly, an extended queue object might want to awaken threads
whenever it is "not full" ($bq->enqueue), "not empty" ($bq->dequeue), or
"empty" ($bq->await_empty).  Using three separate cond variables spares
needless wake-ups, and arbitrary lock association makes it safe, since each
waiter uses the same lock.  (Apache2's apr_queue.c implements a similar queue,
with multiple conditions beneath one big mutex.)

> Questions, questions, questions...  ;-)   Just wondering if and when
> I would need to add similar functionality to forks.pm   ;-)

Sooner rather than later, I hope.  :-)  I find it persuasive that the
two-argument form of cond_wait() mirrors (not just pthread_cond_wait and
cthreads' condition_wait, but also) the COND_WAIT macro inside Perl itself.

-Mike

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About