You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Evgueni Brevnov <ev...@gmail.com> on 2006/10/19 16:03:06 UTC

[drlvm][threading] Infinite loop in atomic16_inc/atomic16_dec?

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


Re: [drlvm][threading] Infinite loop in atomic16_inc/atomic16_dec?

Posted by Evgueni Brevnov <ev...@gmail.com>.
On 10/20/06, Weldon Washburn <we...@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 <ar...@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 <ev...@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


Re: [drlvm][threading] Infinite loop in atomic16_inc/atomic16_dec?

Posted by Weldon Washburn <we...@gmail.com>.
Evgueni,
Please also test on Linux.  This looks like a reasonable patch to me.
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()??


On 10/19/06, Artem Aliev <ar...@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 <ev...@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

Re: [drlvm][threading] Infinite loop in atomic16_inc/atomic16_dec?

Posted by Evgueni Brevnov <ev...@gmail.com>.
The patch for the problem was created
http://issues.apache.org/jira/browse/HARMONY-1929

Evgueni

On 10/20/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> On 10/19/06, Artem Aliev <ar...@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.
>
> Oh, I see. Sure, I'll provide a patch soon....
> Evgueni
> >
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> > On 10/19/06, Evgueni Brevnov <ev...@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
> >
> >
>

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


Re: [drlvm][threading] Infinite loop in atomic16_inc/atomic16_dec?

Posted by Evgueni Brevnov <ev...@gmail.com>.
On 10/19/06, Artem Aliev <ar...@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.

Oh, I see. Sure, I'll provide a patch soon....
Evgueni
>
>
> Thanks
> Artem
>
>
>
>
> On 10/19/06, Evgueni Brevnov <ev...@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
>
>

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


Re: [drlvm][threading] Infinite loop in atomic16_inc/atomic16_dec?

Posted by Artem Aliev <ar...@gmail.com>.
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 <ev...@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