harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Date Sat, 11 Nov 2006 22:48:59 GMT
All,

Evgueni's patch is a step in the right direction. Considering
pthread_mutex_init as a conventional example, monitor shouldn't be
locked at _init function. Test errors on Linux can just tell us that
there are more places that rely on the incorrect contract of the
function.

-- Alexei

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


-- 
Thank you,
Alexei

Mime
View raw message