This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: for "Strange testsuite/thread/pthread1.cc"
- From: "H . J . Lu" <hjl at lucon dot org>
- To: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Sat, 26 Jan 2002 00:24:00 -0800
- Subject: Re: PATCH: for "Strange testsuite/thread/pthread1.cc"
- References: <20020125173733.A25178@lucon.org> <200201260335.g0Q3Zje05350@latour.rsch.comm.mot.com>
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.