This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: for "Strange testsuite/thread/pthread1.cc"


On Fri, Jan 25, 2002 at 09:35:45PM -0600, Loren James Rittle wrote:
> [...]
> > I don't see how it can work. You have no control which thread will run
> > at any given time. As the result, produce/consume may send singal to 
> > itself, which leads to dead lock. It happens on Linux/mips. May I ask
> > why only one condition variable is used?
> 
> Hi H.J.,
> 
> Thanks for the report.  This code was written long before I knew it
> was going in as a portable test case.  Even so, I think the code is
> logically correct against the standard.  However, I could agree that
> it does something quirky (i.e. not in common use).  Since it is
> debatable whether the issue is in the test case or the thread
> implementation (I don't wish to have the debate since I don't have a
> copy of 1003.1c-1995 handy at the moment) and since the purpose of the
> test case is not to stress test a POSIX thread implementation, I will
> change the test to use one condition variable per signaling direction.
> 
> Regarding why only one condition variable is required in this special
> case IMHO: There are exactly two threads sharing any particular
> condition variable.  May a thread ever send a condition signal to
> itself?  By definition, absolutely not.  In practice, I think this is
> the issue with the deadlocking thread implementation (I vaguely recall
> this issue having been discussed many moons ago).
> 

You are right. I looked at the code again. It is ok. The bug is
somewhere else.


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]