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] Infinite loop in atomic16_inc/atomic16_dec?
Date Fri, 20 Oct 2006 13:14:48 GMT
On 10/20/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> Evgueni,
> Please also test on Linux.  This looks like a reasonable patch to me.
Unfortunately, I don't have access to Linux today (work from home).

> Regarding the 16-bit CAS.  A long time ago, there was a 16-bit, byte-aligned
> field for thread ID.  monenter() would do a 16-bit CAS.  Maybe this is left
> over from old monenter()??

There is still 16-bit field for Thread ID which keeps ID of the thread
holding object lock. port_atomic_cas16 is used to operate with it...As
Artem said susped_request field used to be 16-bit value some time ago.
I think that's the main reason why 16-bit CAS was used. Seems like
somebody changed 16-bit value to 32-bit but failed to fix atomic
dec/inc operations.

Evgueni

>
>
> On 10/19/06, Artem Aliev <artem.aliev@gmail.com> wrote:
> >
> > Eugeny,
> >
> > > The problem can be easily fixed by changing int16 to unit16 in
> > > atomic16_dec. Do you think this is accaptable way to fix the problem.
> >
> >
> > > BTW, could somebody explain why 16-bit atomic operation is used for
> > > 32-bit value?
> > The suspend_request could be 16bit value some time ago.
> > Could you please file a JIRA issue with a patch.
> > It looks reasonable to replace  inc16 by inc32 as a fix.
> >
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> > On 10/19/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > > Hi,
> > >
> > > Today, I had several hangs of cunit tests. It turned out to be
> > > infinite cycling in
> > > while loop of atomic16_inc/atomic16_dec (see
> > > vm/thread/src/thread_native_suspend.c)
> > >
> > > Here is a snip of assembler code produced by msvc for atomic16_dec:
> > >
> > > call        port_atomic_cas16 (10004A90h)
> > > add         esp,0Ch
> > > movzx       edx,ax <-----------------------------zero extention
> > > movsx       eax,word ptr [old_value] <----sign extention
> > > cmp         edx,eax
> > > je          atomic16_inc+45h (10004A15h)
> > >
> > > The problem can be easily fixed by changing int16 to unit16 in
> > > atomic16_dec. Do you think this is accaptable way to fix the problem.
> > >
> > > BTW, could somebody explain why 16-bit atomic operation is used for
> > > 32-bit value?
> > >
> > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

---------------------------------------------------------------------
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


Mime
View raw message