harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Date Mon, 13 Nov 2006 10:41:32 GMT
Could someone familiar with classlib's implementation comment on that ....?

Thanks in advance.
Evgueni

On 11/13/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> 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 <artem.aliev@gmail.com> 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 <evgueni.brevnov@gmail.com> 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
> > >
> >
>

Mime
View raw message