harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][threading] Possible race condition in implementation of conditional variables?
Date Fri, 13 Oct 2006 05:34:06 GMT
On 10/12/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> Hi,
> I do the following:
> hythread_suspend_disable();
> <do unsafe actions>
> hysem_wait(semaphore);
> <do unsafe actions>
> hythread_suspend_enable();
> By saying hythread_suspend_disable(); I expect the thread can't be
> suspended until hythread_suspend_enable() is called.

Some observations:

The above code sequence is a really good diagnostic test.  It definitely
breaks the suspend enable/disable model.  It is an illegal code sequence
that can cause the entire system to hang if there is a GC while stuck in a
semaphore wait.  If anything, I expect the system to hang, not reset the
enable/disable state and continue executing.

I don't understand why hysem_wait() *enables* the GC.  My only guess is that
someone hit a problem where the system deadlocked in hysem_wait() and hacked
in the enable.  Any clues who did this and why they did this??

How about putting an assert(gc enabled ==  true) ; in hysem_wait() {...} and
debugging the cases where gc is not enabled and the next line of code
executes a wait.

But hysem_wait()
> resets disabled mode and enables thread suspension. As a result GC can
> happen when it must not. hysem_wait is based on conditional variables
> so the same can happen when conditional variables is used.
> Do you see the problem here? Or I miss something?
> Thanks
> Evgueni
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Weldon Washburn
Intel Middleware Products Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message