void some_function()
{
pthread_mutex_lock(&somelock);
//Do something
pthread_mutex_unlock(&somelock);
}
Thread safety
Author
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
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..
Quote:Original post by gommoIt's usually implemented as an atomic read-modify-write instruction that locks the shared memory bus.
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.
So there's no need to worry.
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,
Regards,
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
Critical sections are meant for single app syncronization and are a heck of a lot more light weight.
Cheers
Chris
Quote:Original post by Emmanuel DelogetNot 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)
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 :)
Quote:Original post by chollida1I'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)
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.
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
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
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.
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.
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.
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
