## Recommended Posts

With this years releases of Intel's dual core chips I've started thinking about thread safety more. I spent my working hours on a massively threaded realtime application but this is only on a single CPU. I've never programmed on a multicore cpu (Save a P4 hyperthreading one). How do mutexes ensure thread safety when there are multiple CPU's that are running threads. For instance
void some_function()
{

//Do something

}


On a single CPU system, calling a lock that is an atomic operation (By disabling interrupts briefly??) ensures that the lock is obtained (if possible) and even in the event of a thread switch, as the locking operating is atomic it ensures that only one thread can get the lock. However, with 2 or more CPU's that are executing in ACTUAL parrallel, how is this ensured?? Is there extra instructions which disable thread switches throughout all CPU's etc..

##### Share on other sites
Quote:
 Original post by gommoOn a single CPU system, calling a lock that is an atomic operation (By disabling interrupts briefly??) ensures that the lock is obtained (if possible) and even in the event of a thread switch, as the locking operating is atomic it ensures that only one thread can get the lock.
It's usually implemented as an atomic read-modify-write instruction that locks the shared memory bus.
So there's no need to worry.

##### Share on other sites
Having more than one CPU should not be your concern. From a programmer point of view, it works the same. You really don't have to worry. If your program is thread aware than you should make it thread safe. Everything should be ok :)

Regards,

##### Share on other sites
If your only worried about one process use critical sections instead of mutexes. Mutexes are meant for Operating System wide syncronization. Most people use them in their apps and end up slowing them down due to their huge cost of obtaining and freeing.

Critical sections are meant for single app syncronization and are a heck of a lot more light weight.

Cheers
Chris

##### Share on other sites
Quote:
 Original post by Emmanuel DelogetHaving more than one CPU should not be your concern. From a programmer point of view, it works the same. You really don't have to worry. If your program is thread aware than you should make it thread safe. Everything should be ok :)
Not so, there are many bugs that would show up on multicore that wouldn't appear on single core in a threaded app. (edit: I should clarify. They're bugs on both, but you might never even see it happen on single core simply because the race condition is one in a million, whereas on multicore it becomes one in ten)

Quote:
 Original post by chollida1If your only worried about one process use critical sections instead of mutexes. Mutexes are meant for Operating System wide syncronization. Most people use them in their apps and end up slowing them down due to their huge cost of obtaining and freeing.Critical sections are meant for single app syncronization and are a heck of a lot more light weight.
I'm not sure what critical sections are, but mutexes, semaphores, etc are standard ways of implementing locking. There's no reason to discourage their use... (and huge cost? that's making many assumptions. futexes on linux, for example, are incredibly fast)

##### Share on other sites
Hehe

I think you misunderstood me :) I didnt' want to discourage their use, I just wanted to point out that there are usually better allternatices to mutexes. YOu pointed out one for Linux and I pointed out one for OS X and the windows.

Cheers
Chris

##### Share on other sites
Oh I see. I used the word mutex to pretty much mean anything that has the same behavior as a mutex. I looked at Mac's critical regions a bit and it looks pretty much the same. I'm going to avoid the headache of venturing into msdn...

I think pthreads might even use the best available locking primitive, so it'd still end up using critical regions in the end. I'll double check this claim, I suppose... gimme a minute.

##### Share on other sites
Mutexes are typically implemented using atomic bus transactions, where a single CPU is guaranteed to be able to read-modify-write a memory location somehow. On x86, this is done with the LOCK instruction prefix. On PPC, it's done with cache line reservations and conditional stores.

##### Share on other sites
There's no mention of preference for critical sections in the performance section on this page...

##### Share on other sites
Check out this site
http://support.microsoft.com/default.aspx?scid=kb;en-us;105678

C-Junkie Good call I was misusing the term on the Mac, mutex is preferable, its windows where the advice still stands. I guess thats what I get for comming from a windows background:)

Cheers
Chris

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
627701
• Total Posts
2978702

• 21
• 14
• 12
• 10
• 12