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 weldonwjw@gmail.com designates
 66.249.92.175 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:references;
        b=BgdtYWwfoLCwa2mzptNXZeTs++rrInICkadq8uNo4oarAHP7a2H10f7KAQSkixd2vHgK7o43zZqprJoFBBINw/5sNwwg6uHOVWzN4++8gcKlCJqffGACPqVUbfJgbvG8rHJPTwrU1SSeAO3KmIHUQUq+VSRWdS7HvKlXSrjsN4g=
Message-ID: <4dd1f3f00610311338r3513536cw72610a2c513f4832@mail.gmail.com>
Date: Tue, 31 Oct 2006 13:38:30 -0800
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][threading] Possible race condition in implementation of
 conditional variables?
In-Reply-To: <4dd1f3f00610122234w693f6feaw1ed023bbbedb8edf@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11948_31856256.1162330710234"
References: <e29119980610122153x1ba45f0dt2450e7b766c1aea1@mail.gmail.com>
	 <4dd1f3f00610122234w693f6feaw1ed023bbbedb8edf@mail.gmail.com>

------=_Part_11948_31856256.1162330710234
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I did some digging.  It looks like what's in today's svn HEAD does the
following:


thread_native_semaphore.c::hysem_wait() calls

 thread_native_semaphore.c::sem_wait_impl() calls

  thread_native_condvar.c::condvar_wait_impl()  which does the following:

  {

      disable_count = reset_suspend_disable();

      apr_thread_cond_wait();

      set_suspend_disable(disable_count);

   }


The potential problem is that
thread_native_suspend.c::reset_suspend_disable() does the following:

 {

     int dis = self->suspend_disable_count;

     self->suspend_disable_count = 0;

}


This needs more investigation.  The big worry at this point is why
reset_suspend_disable() exists in the first place?  There may be a
misunderstanding how GC suspend enable/disable should work.  It also looks
like there is confusion regarding the functionality required for GC suspend
enable/disable and the functionality required for Java Thread
synchronization.   While they have some overlapping similarities, the also
have unique distinct semantics.


Evgueni, Artem, does any of the above make sense?


For completeness, I tracked down the GC suspend enable/disable code.  It is
below:


thread_native_suspend.c:: hythread_is_suspend_enabled(){

        return tm_self_tls->suspend_disable_count == 0;

}


On 10/12/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>
>
>
> On 10/12/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> >
> > Hi,
> >
> > I do the following:
> >
> > hythread_suspend_disable();
> > <do unsafe actions>
> > hysem_wait(semaphore);
> > <do unsafe actions>
> > hythread_suspend_enable();
> >
> > By saying hythread_suspend_disable(); I expect the thread can't be
> > suspended until hythread_suspend_enable() is called.
>
>
> Some observations:
>
> 1)
> The above code sequence is a really good diagnostic test.  It definitely
> breaks the suspend enable/disable model.  It is an illegal code sequence
> that can cause the entire system to hang if there is a GC while stuck in a
> semaphore wait.  If anything, I expect the system to hang, not reset the
> enable/disable state and continue executing.
>
> 2)
> I don't understand why hysem_wait() *enables* the GC.  My only guess is
> that someone hit a problem where the system deadlocked in hysem_wait() and
> hacked in the enable.  Any clues who did this and why they did this??
>
> 3)
> How about putting an assert(gc enabled ==  true) ; in hysem_wait() {...}
> and debugging the cases where gc is not enabled and the next line of code
> executes a wait.
>
>
> But hysem_wait()
> > resets disabled mode and enables thread suspension. As a result GC can
> > happen when it must not. hysem_wait is based on conditional variables
> > so the same can happen when conditional variables is used.
> >
> > Do you see the problem here? Or I miss something?
> >
> > Thanks
> > Evgueni
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

------=_Part_11948_31856256.1162330710234--