Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of artem.aliev@gmail.com
 designates 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=qNGX5XaO0WeXEYMmE8aUDnhdYX7m8lk70zQ6WNATxVoJxui4iFXLYne763aOZ7xH34r0IilXZOUCjvVzNdunexfgj7B/nMRA9kZSCM7D7SPGrUVWlMT/3yUNpbz98nJn1YtXAn7wcQpRPRx4yTquyxGxj/4vvFFMkxoFuSdmVpU=
Message-ID: <187bb05d0611130657g63c573cfyda6c7fcf3d6e5153@mail.gmail.com>
Date: Mon, 13 Nov 2006 17:57:01 +0300
From: "Artem Aliev" <artem.aliev@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][threading] Should hythread_monitor_init() aquire the
 monitor?
In-Reply-To: <e29119980611130241w1a12fbe1y42869fdc07dbe30@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e29119980611100645g629764d7xf5c72f78090bea81@mail.gmail.com>
	 <187bb05d0611130138o7c870257g664c6b35ae7b11bb@mail.gmail.com>
	 <e29119980611130240i7ce72a40gc2d490f5b90bae6b@mail.gmail.com>
	 <e29119980611130241w1a12fbe1y42869fdc07dbe30@mail.gmail.com>

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 <evgueni.brevnov@gmail.com> wrote:
> 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
> > > >
> > >
> >
>