On 10/12/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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:
1)
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.
2)
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??
3)
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
