Could someone familiar with classlib's implementation comment on that ....?
Thanks in advance. Evgueni On 11/13/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
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 > > >
