Re: [perl #19088] Thread::Queue
On Wed, Jul 06, 2005 at 08:32:52AM -0700, Michael G Schwern wrote:
> > > The original is like:
> > >
> > > sub dequeue {
> > > my $q = shift;
> > > lock(@$q);
> > > cond_wait @$q until @$q;
> > > cond_signal @$q if @$q > 1;
> > > return shift @$q;
> > > }
> > >
> > > Should it be safer if it goes like this?
> > >
> > > sub dequeue {
> > > my $q = shift;
> > > lock(@$q);
> > > cond_wait @$q until @$q;
> > > my $p = shift @$q;
> > > cond_signal @$q if @$q >= 1;
> > > return $p;
> > > }
The original code is safe as-is. The whole body of dequeue occurs while
it has the lock on @$q (apart from temporarily relinquishing it during
cond_wait). The cond_signal bit is only for the specific case that more
than one item was pushed onto the queue, and that there is more than one
consumer thread waiting to remove it: the first thread to get its snout
in the trough signals to its compatriots (if any) that there is more
data available: one of those compatriots will be awoken and will try to
grab the lock; in the meantime the first consumer still has the lock,
pulls one item from the queue and returns it, freeing up the lock. At
which point the second compatriot will get the lock and ppop one too.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
Re: [perl #19088] Thread::Queue
On Wed, Jul 06, 2005 at 09:12:29AM -0400, Lihn, Steve wrote:
> It appears identical. I am not sure why I thought it is better.
> Sorry about it...
Hmm, its threads so appearing identical is not always identical.
If I had to guess the intention was to protect all of @$q from being
sucked away? So that if something empties @$q you still have $p to return.
Best guess I can make not knowing much about Thread::Queue.
> > The original is like:
> >
> > sub dequeue {
> > my $q = shift;
> > lock(@$q);
> > cond_wait @$q until @$q;
> > cond_signal @$q if @$q > 1;
> > return shift @$q;
> > }
> >
> > Should it be safer if it goes like this?
> >
> > sub dequeue {
> > my $q = shift;
> > lock(@$q);
> > cond_wait @$q until @$q;
> > my $p = shift @$q;
> > cond_signal @$q if @$q >= 1;
> > return $p;
> > }
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
RE: [perl #19088] Thread::Queue
It appears identical. I am not sure why I thought it is better.
Sorry about it...
Steve Lihn
-Original Message-
From: Michael G Schwern via RT [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 05, 2005 1:29 AM
To: Lihn, Steve
Subject: [perl #19088] Thread::Queue
> [EMAIL PROTECTED] - Thu Dec 12 14:55:24 2002]:
> I am looking at the Thread::Queue code.
> The original is like:
>
> sub dequeue {
> my $q = shift;
> lock(@$q);
> cond_wait @$q until @$q;
> cond_signal @$q if @$q > 1;
> return shift @$q;
> }
>
> Should it be safer if it goes like this?
>
> sub dequeue {
> my $q = shift;
> lock(@$q);
> cond_wait @$q until @$q;
> my $p = shift @$q;
> cond_signal @$q if @$q >= 1;
> return $p;
> }
Why would this be safer?
--
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New
Jersey, USA 08889), and/or its affiliates (which may be known outside the
United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as
Banyu) that may be confidential, proprietary copyrighted and/or legally
privileged. It is intended solely for the use of the individual or entity named
on this message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then delete
it from your system.
--
