Oops,
You were right. I take a llook into classlib hythread code. It looks like I incorrectly understand the documentation. This is a bug. Thanks Artem On 11/13/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
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 > > > > > >
