PATCH: for "Strange testsuite/thread/pthread1.cc"
H . J . Lu
Sat Jan 26 00:24:00 GMT 2002
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
More information about the Libstdc++