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 Sat, 11 Nov 2006 17:53:59 GMT
hmmm.... strange. The patch was tested on multi-processor system
running SUSE9. I will check if the patch misses something. Anyway, we
need to wait with the patch submission until we 100% sure how
hythread_monitor_init should behave.

Thanks
Evgueni

On 11/11/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> On Friday 10 November 2006 17:45 Evgueni Brevnov 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?
>
> It might be that semantic is different on different platforms which is
> probably even worse. Your patch in HARMONY-2149 breaks nearly all of
> acceptance tests on Linux while everything on Windows works (ok I tested on
> laptop with 1 processor while Linux was a HT server, sometimes it is
> important for threading).
>
> I think we need more investigation on whether or not the monitor has to be
> locked in init.
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>

Mime
View raw message