Hello Artem, Are you 100% sure? I've looked at the classlib's implementation and can't find where the monitor is acquired. Moreover if you look at the initializeSignalTools() located in modules\portlib\src\main\native\port\linux\hysignal.c you will find that it initializes new monitors with hyhtread_monitor_init_with_name and never frees these monitors. That turned out to be the reason of a deadlock in HARMONY-2006.
Thanks Evgueni On 11/13/06, Artem Aliev <[EMAIL PROTECTED]> wrote:
> It turned out that DRL > implementation of hythread_monitor_init / > hythread_monitor_init_with_name initializes and acquires a monitor. Eugeni, Both drlvm and classlib hythread work this way. This original hythread design that for compatibility reason was implemented in drlvm. Thanks Artem On 11/10/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: > Hi, > > While investigating deadlock scenario which is described in > HARMONY-2006 I found out one interesting thing. It turned out that DRL > implementation of hythread_monitor_init / > hythread_monitor_init_with_name initializes and acquires a monitor. > Original spec reads: "Acquire and initialize a new monitor from the > threading library...." AFAIU that doesn't mean to lock the monitor but > get it from the threading library. So the hythread_monitor_init should > not lock the monitor. > > Could somebody comment on that? > > Thanks > Evgueni >
