thread synchronization

Index > Main > thread synchronization

Goto page 1, 2 Next

Author

Thread

tthsqe

Joined: 20 May 2009
Posts: 767

tthsqe 01 Mar 2010, 03:16

Maybe if the search function wasn't broken I could have found a previous post about this, but I wondering what the best way would be to have threads communicate with each other though a few shared variables (like a CREW machine).

01 Mar 2010, 03:16

shoorick

Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine

shoorick 01 Mar 2010, 05:49

OS? events, mutexes, criticalsections...

01 Mar 2010, 05:49

sinsi

Joined: 10 Aug 2007
Posts: 786
Location: Adelaide

sinsi 01 Mar 2010, 05:59

Isn't there an opcode (prefix?) hint for a spinlock? Depends on what OS you are using I guess...

01 Mar 2010, 05:59

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19874
Location: In your JS exploiting you and your system

revolution 01 Mar 2010, 06:30

tthsqe: Do you want thread synchronization or thread communication or both. Because they are entirely different things. To synchronise means to ensure order. To communicate means to pass information. You can have one or the other or both, it depends upon your application.

It would help if you gave more information on what you are trying to do otherwise any advice given here will likely be not what you are looking for. And remember to say which OS you are intending to target, that makes a big difference.

01 Mar 2010, 06:30

tthsqe

Joined: 20 May 2009
Posts: 767

tthsqe 01 Mar 2010, 17:37

Oops, I don't think I meant a CREW machine... anyways, the following situation shoudl suffice:

I have a global variable n=0. When each thread executes n++, I would want it to behave as expected, that is n reflects the total number of times the statement was excuted - so no side effects caused by two threads reading the same value of n at the same time then both writing back n+1 to n when it really should be n+2.

Also, windows.

01 Mar 2010, 17:37

MHajduk

Joined: 30 Mar 2006
Posts: 6110
Location: Poland

MHajduk 01 Mar 2010, 17:50

Perhaps you may just use semaphores here? It could be realized with such atomic assembler instructions as XADD and CMPXCHG (check Intel manuals and other resources for proper examples Wink

01 Mar 2010, 17:50

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 01 Mar 2010, 22:53

MHajduk,

Why not lock inc? Both xadd and cmpxchg look like an overkill (in this particular case).

__________
tthsqe,

Win32's way to do it is InterlockedIncrement() (XP SP2 implements it via xadd Wink

)

01 Mar 2010, 22:53

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19874
Location: In your JS exploiting you and your system

revolution 01 Mar 2010, 23:05

Note that both xadd and cmpxchg need a lock prefix to make them atomic.

Further note that not all processors support xadd or cmpxchg.

Also note that lock inc is fine if you don't care about the previous value.

Lastly note that any instruction that involves a lock prefix will seriously degrade performance. For variables that need to be updated frequently this may be a consideration.

01 Mar 2010, 23:05

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 01 Mar 2010, 23:24

Quote:

Further note that not all processors support xadd or cmpxchg.

Besides processors prior to 80486 is there any other?

01 Mar 2010, 23:24

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 01 Mar 2010, 23:30

revolution,

To be atomic, it have to employ #LOCK protocol.

01 Mar 2010, 23:30

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19874
Location: In your JS exploiting you and your system

revolution 01 Mar 2010, 23:34

baldr wrote:

revolution,

To be atomic, it have to employ #LOCK protocol.

Is there an echo? Wink

revolution wrote:

Note that both xadd and cmpxchg need a lock prefix to make them atomic.

01 Mar 2010, 23:34

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19874
Location: In your JS exploiting you and your system

revolution 01 Mar 2010, 23:38

LocoDelAssembly wrote:

Quote:
Further note that not all processors support xadd or cmpxchg.
Besides processors prior to 80486 is there any other?

Yeah, it looks like using them will make your code 486+ only.

01 Mar 2010, 23:38

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 02 Mar 2010, 00:13

revolution,

Not an echo, just repercussion. Wink

My comment was about performance degradation: #LOCK is a must for them to be atomic.

02 Mar 2010, 00:13

tthsqe

Joined: 20 May 2009
Posts: 767

tthsqe 02 Mar 2010, 08:16

How about if the updating function is not a single instruction like inc that can be used with lock? I was thinking of something like:

Code:

start:
t = [CT]
x = [N]
update x
if t = [CT]        ; if [N] has not been updated in between
   [N] = x
   [CT]++
else
   goto start
endif

here, N, and CT = 0 are global; x and t are local.

But I'm not sure exactly sure what instructions need to be made atomic or how to do this.

02 Mar 2010, 08:16

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 02 Mar 2010, 08:34

tthsqe,

That's what synchronization objects are for. Look up critical section in MSDN.

02 Mar 2010, 08:34

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19874
Location: In your JS exploiting you and your system

revolution 02 Mar 2010, 08:36

tthsqe: You need a proper spinlock to do atomically.

In the above pseudo-code: between 'if t=[CT]' and '[N]=x' you have a period of vulnerability. It may help you think about what would happen if two CPUs are in perfect lock-step and see what would happen to the memory values.

02 Mar 2010, 08:36

tthsqe

Joined: 20 May 2009
Posts: 767

tthsqe 02 Mar 2010, 09:47

Ok, I'll look into that more. How about a simple tast synchronization - making sure all thread finish a task before any thread starts the next. I was think of something like this:

Code:

ThreadStart:   ; start with ct1 = 0
        task1
        mov     [ct2],0
   lock inc     [ct1]
    @@: cmp     [ct1],[ThreadCount]
        jl      @b
        task2
        mov     [ct3],0
   lock inc     [ct2]
    @@: cmp     [ct2],[ThreadCount]
        jl      @b
        task3
        mov     [ct1],0
   lock inc     [ct3]
    @@: cmp     [ct3],[ThreadCount]
        jl      @b
        ...

It seems that we need to cycle through three counters to avoid any possible side effects.

02 Mar 2010, 09:47

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19874
Location: In your JS exploiting you and your system

revolution 02 Mar 2010, 10:01

tthsqe: I think you are trying to reinvent the wheel. Wink

Perhaps you would like to read up about WaitForMultipleObjects and CreateSemaphore. Don't try to fight the OS, use it for what it was designed for.

02 Mar 2010, 10:01

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19874
Location: In your JS exploiting you and your system

revolution 02 Mar 2010, 10:27

tthsqe wrote:

How about if the updating function is not a single instruction like inc that can be used with lock? I was thinking of something like:
Code:
start:
t = [CT]
x = [N]
update x
if t = [CT]        ; if [N] has not been updated in between
   [N] = x
   [CT]++
else
   goto start
endif    
here, N, and CT = 0 are global; x and t are local.

But I'm not sure exactly sure what instructions need to be made atomic or how to do this.

I think that perhaps my mention of the performance hit of using lock has scared you away from it? Anyhow, there is no choice in x86 architecture, you have to use the lock prefix.¹ You can't make any atomic access code that does not lock, it is impossible, the hardware only responds to lock and no other sequence of code will save you from using it.

¹ Using xchg has an implicit lock, so that also won't allow you to avoid the bus lock.

02 Mar 2010, 10:27

hopcode

Joined: 04 Mar 2008
Posts: 563
Location: Germany

hopcode 02 Mar 2010, 13:28

perhaps useful
http://www.azillionmonkeys.com/qed/asmexample.html
browse to para 15 .63 bit atomic counter.

Cheerz, Very Happy

hopcode

02 Mar 2010, 13:28

Goto page 1, 2 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum