How to use 'lock' prefix to make instruction atomic (in amulti-threaded program)

#1 08-23-2008, 11:36 AM

Hi all,
I am writing a multi-threaded assembly program with POSIX threads.
There is a global variable that all thread can modify. Each thread may
increment or decrement this variable, global_counter.
And this is how i wrote for each thread (at&t syntax):
lock addl $1, global_counter
lock subl $1, global_counter
%% Or use 'inc' and 'dec' instruction instead of add/sub
In the main thread, it requires to read the value of global_counter
atomically, this is what i wrote:
movl $0, %eax
lock addl global_counter, %eax

However, the assembler always complains "illegal instruction". Did i
somehow misuse the lock prefix, or I misunderstood the purpose of the
lock prefix? Any suggestions on how to get it work?

Thanks a lot.

cheers,

xiao-lei

#2 08-23-2008, 03:00 PM

On Sat, 23 Aug 2008 08:36:59 -0700 (PDT), climber.cui
<spamtrap@crayne.org> wrote:

>Hi all,
> I am writing a multi-threaded assembly program with POSIX threads.
>There is a global variable that all thread can modify. Each thread may
>increment or decrement this variable, global_counter.
> And this is how i wrote for each thread (at&t syntax):
> lock addl $1, global_counter
> lock subl $1, global_counter
> %% Or use 'inc' and 'dec' instruction instead of add/sub
> In the main thread, it requires to read the value of global_counter
>atomically, this is what i wrote:
> movl $0, %eax
> lock addl global_counter, %eax
>
> However, the assembler always complains "illegal instruction". Did i
>somehow misuse the lock prefix, or I misunderstood the purpose of the
>lock prefix? Any suggestions on how to get it work?
>
Try the lock on a seperate line just above the add or sub
--
ArarghMail808 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

#3 08-23-2008, 05:10 PM

On Sat, 23 Aug 2008 08:36:59 -0700 (PDT)
"climber.cui" <spamtrap@crayne.org> wrote:

> Did i
> somehow misuse the lock prefix, or I misunderstood the purpose of the
> lock prefix?

The lock prefix is only valid on instructions which modify memory.
Reading from memory neither requires nor allows the prefix.

--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html

#4 08-23-2008, 07:24 PM

On Sat, 23 Aug 2008 14:10:56 -0700, Charles Crayne
<spamtrap@crayne.org> wrote:

>On Sat, 23 Aug 2008 08:36:59 -0700 (PDT)
>"climber.cui" <spamtrap@crayne.org> wrote:
>
>> Did i
>> somehow misuse the lock prefix, or I misunderstood the purpose of the
>> lock prefix?
>
>The lock prefix is only valid on instructions which modify memory.
>Reading from memory neither requires nor allows the prefix.

The OPs first two examples do modify memory, the third doesn't.
--
ArarghMail808 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

#5 08-24-2008, 03:17 AM

On Aug 23, 5:10 pm, Charles Crayne <spamt...@crayne.org> wrote:
> On Sat, 23 Aug 2008 08:36:59 -0700 (PDT)
>
> "climber.cui" <spamt...@crayne.org> wrote:
> > Did i
> > somehow misuse the lock prefix, or I misunderstood the purpose of the
> > lock prefix?
>
> The lock prefix is only valid on instructions which modify memory.
> Reading from memory neither requires nor allows the prefix.
>
> --
> Chuckhttp://www.pacificsites.com/~ccrayne/charles.html

Yes, it works. Thanks.
But, if i wrote :
cmp $0, global_counter
Is it always going to be atomic read (I mean, reading the value of
global_counter) ?

xiao-lei

#6 08-24-2008, 05:49 AM

"climber.cui"asked:
....
> But, if i wrote :
> cmp $0, global_counter
> Is it always going to be atomic read (I mean, reading the value of
> global_counter) ?

Of course the read is atomic by itself, but any following instruction
(like conditional jump, cmov) may rely on a meanwhile altered value.
So the CPU-designers gave us two variants of fully atomic switches:

____________MP solutions
CHECK_GRANT_HLL:
mov ecx,false ;assuming true means 'free' yet.
mov eax,true
lock cmpxchg,dword[global_grant_if_free], ecx
;eax true means granted and modified to false
;eax false means occupied
ret ; also possible: jz granted...
___________MP solutions
CHECK_GRANT_ASM:
mov eax,grant_if_free_bitnr ;can span a range +/-256MByte
lock bts dword [global_flags],eax
;a set CY means the flag was SET and remains SET(occupied)
;NC means it was clear, so granted and SET yet.
jnc granted
....
__
wolfgang

#7 08-24-2008, 01:21 PM

"Wolfgang Kern" <spamtrap@crayne.org> writes:
> "climber.cui"asked:
> ...
>> But, if i wrote :
>> cmp $0, global_counter
>> Is it always going to be atomic read (I mean, reading the value of
>> global_counter) ?
>
> Of course the read is atomic by itself,

Even if global_counter is misaligned? I've known architectures
where the two halves of the fetch from memory (or should I say
two fetches from memory) would leave room for a race condition,
and currently have no reason to believe that x86 would be any
different. However, it's theoretically possible that Intel
wanted to preserve the apparent atomic nature of such a read.

Phil
--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
-- George Bernard Shaw (1856-1950), Preface to Androcles and the Lion

#8 08-24-2008, 04:34 PM

Phil Carmody wrote:

>>> cmp $0, global_counter
>>> Is it always going to be atomic read (I mean, reading the value of
>>> global_counter) ?

>> Of course the read is atomic by itself,

> Even if global_counter is misaligned? I've known architectures
> where the two halves of the fetch from memory (or should I say
> two fetches from memory) would leave room for a race condition,
> and currently have no reason to believe that x86 would be any
> different. However, it's theoretically possible that Intel
> wanted to preserve the apparent atomic nature of such a read.

I sure hope that a 'global counter' will never reside unaligned

Can't remember where I read about x86 instructions will be never
intercepted in the middle of their job, perhaps already with 286/287 ?
Misaligned/cachebound crossing data will see penalty cycles anyway.

__
wolfgang

#9 08-24-2008, 04:46 PM

On Sun, 24 Aug 2008 20:21:26 +0300
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:

> I've known architectures
> where the two halves of the fetch from memory (or should I say
> two fetches from memory) would leave room for a race condition,
> and currently have no reason to believe that x86 would be any
> different.

In the 8086/8088 days, this was a potential problem, but since the
introduction of cache memory, the designers have provided ways to
synchronize the caches on two or more processors, and all reads,
and most writes, are atomic. Only those instructions which internally
perform a read->update->write cycle can make use of the LOCK prefix,
although there may be assemblers which will silently discard the
prefix when it is used inappropriately. This has been true since at
least the introduction of the 80386.

--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html

#10 08-25-2008, 01:56 AM

Phil Carmody schrieb:
> "Wolfgang Kern" <spamtrap@crayne.org> writes:
>> "climber.cui"asked:
>> ...
>>> But, if i wrote :
>>> cmp $0, global_counter
>>> Is it always going to be atomic read (I mean, reading the value of
>>> global_counter) ?
>> Of course the read is atomic by itself,
>
> Even if global_counter is misaligned?

Iirc from the document below, global_counter must be
aligned for its read be be atomic.

Intel Memory Ordering White Paper
<www.intel.com/products/processor/manuals/318147.pdf>

Hendrik vdH

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode