Sign in to follow this  

Thread safety

This topic is 4695 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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()
{
  pthread_mutex_lock(&somelock);

  //Do something

  pthread_mutex_unlock(&somelock);
}


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 this post


Link to post
Share on other sites
Quote:
Original post by gommo
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.
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
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 :)
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 chollida1
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.
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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

Share this post


Link to post
Share on other sites

This topic is 4695 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this