Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #919 > unrolled thread

About lockfree_mpmc ...

Back to article view | Back to comp.programming.threads

Contents

  About lockfree_mpmc ... "aminer" <aminer@videotron.ca> - 2012-06-03 14:58 -0500
    Re: About lockfree_mpmc ... "aminer" <aminer@videotron.ca> - 2012-06-03 15:19 -0500

#919 — About lockfree_mpmc ...

Hello,

I think i have forgot something with lockfree_mpmc...

Please follow with me...

The Intel x86 memory model, detailed in Intel 64 Architecture Memory 
Ordering White Paper
and the AMD spec, AMD64 Architecture Programmer's Manual, list a lot of 
memory ordering
guarantees, among them:
Loads are not reordered with other loads.
Stores are not reordered with other stores.
Stores are not reordered with older loads.
In a multiprocessor system, memory ordering obeys causality (memory ordering 
respects transitive visibility).
In a multiprocessor system, stores to the same location have a total order.
In a multiprocessor system, locked instructions have a total order.
Loads and stores are not reordered with locked instructions.

But since on x86 Loads may be reordered with older stores to different 
locations


So please take a look at the following lockfree_mpmc code:

---

function TLockfree_MPMC.push(tm : tNodeQueue):boolean;
var lasttail,newtemp:long;
i,j:integer;
begin

 if getlength >= fsize
  then
      begin
          result:=false;
          exit;
      end;
result:=true;

[1]newTemp:=LockedIncLong(temp);

[2] lastTail:=newTemp-1;
setObject(lastTail,tm);

[3]

repeat

[4] if CAS(tail,lasttail,newtemp)
   then
      begin
       exit;
      end;
sleep(0);
 until false;

end;
---


So the the loads of lasttail and newtemp in [4] line can be reordered
with older stores of lastail and newtemp in [1] [2], so in this case must
i insert an mfence in line [3] to respect the logic of the program?...



Thank you,
Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#920

Hello again,


Sorry, as you have noticied there is loads on
setObject(lastTail,tm) between line [2] and line [4].

And loads are not reordered with older loads on x86

So i think there is no problem with lockfree_mpmc.


Thank you.
Amine Moulay Ramdne


"aminer" <aminer@videotron.ca> wrote in message 
news:jqgc52$d1h$1@dont-email.me...
>
> Hello,
>
> I think i have forgot something with lockfree_mpmc...
>
> Please follow with me...
>
> The Intel x86 memory model, detailed in Intel 64 Architecture Memory 
> Ordering White Paper
> and the AMD spec, AMD64 Architecture Programmer's Manual, list a lot of 
> memory ordering
> guarantees, among them:
> Loads are not reordered with other loads.
> Stores are not reordered with other stores.
> Stores are not reordered with older loads.
> In a multiprocessor system, memory ordering obeys causality (memory 
> ordering respects transitive visibility).
> In a multiprocessor system, stores to the same location have a total 
> order.
> In a multiprocessor system, locked instructions have a total order.
> Loads and stores are not reordered with locked instructions.
>
> But since on x86 Loads may be reordered with older stores to different 
> locations
>
>
> So please take a look at the following lockfree_mpmc code:
>
> ---
>
> function TLockfree_MPMC.push(tm : tNodeQueue):boolean;
> var lasttail,newtemp:long;
> i,j:integer;
> begin
>
> if getlength >= fsize
>  then
>      begin
>          result:=false;
>          exit;
>      end;
> result:=true;
>
> [1]newTemp:=LockedIncLong(temp);
>
> [2] lastTail:=newTemp-1;
> setObject(lastTail,tm);
>
> [3]
>
> repeat
>
> [4] if CAS(tail,lasttail,newtemp)
>   then
>      begin
>       exit;
>      end;
> sleep(0);
> until false;
>
> end;
> ---
>
>
> So the the loads of lasttail and newtemp in [4] line can be reordered
> with older stores of lastail and newtemp in [1] [2], so in this case must
> i insert an mfence in line [3] to respect the logic of the program?...
>
>
>
> Thank you,
> Amine Moulay Ramdane.
>
>
> 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web