Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm not sure how the locks will work with multi processors/cores, I'm going to use shared memory in my application or FIFO, what worries me is the locks, I have a server with 2-CPU, how the lock will be able to lock a variable on one CPU while the another operation went to the 2nd CPU for the same variable? I'm in Linux environment using C, I've searched the web for some useful info, appreciate your help

share|improve this question
Locking works conceptually quite simply. What you should watch out for is how variables are synchronized across cores. You can't assume, for example, that if you have a pointer that is shared across threads that dereferencing the pointer will yield the same result in both threads. I would advise you against using shared mutable memory if you can avoid it, it makes everything more complicated and won't necessarily result in a linear speedup (in fact it's likely that it won't). – dan_waterworth Jul 17 '12 at 20:24
You mean using FIFO is better? – poly Jul 17 '12 at 21:32
there isn't a "one size fits all" solution. The best approach for you is going to depend on the problem you're solving, but with only 2 cores available to you, it's likely that the extra capacity you'd get from multithreading won't overcome the communication overhead unless your problem is embarrassingly parallel. – dan_waterworth Jul 18 '12 at 12:51
up vote 2 down vote accepted

Intel articles offers a good point of view about this

Also there is a small article about the top 3 solutions in multithreading programming

You didn't specify this, but if you are on Linux and you are programming in C you are probably talking about pthreads and this is a beginner tutorial that covers the main aspects of this topic

share|improve this answer

Assuming you're using pthreads, you have to be aware that locks are implemented as functions and macros.

That means that a lock doesn't make a variable available or not to a CPU, nor they send operations to the other(s) CPU(s). What you do is to spawn threads, calling pthread_create() with a function pointer as a parameter. Typically several threads are spawned with the same function and different parameters, so each runs the same code slightly differently.

Ideally, most of the code should work on different data, allocating private blocks so that each thread can run without checking for collisions.

Of course, there's always some shared part, or some communication between threads, or some common store structure. For this you use locks.

In short, every shared resource must have a lock, and before trying to access the resource you have to acquire the lock using pthread_mutex_lock() or a similar function, and release it with pthread_mutex_unlock() just after using the resource.

When no other thread was trying to use the same resource, these functions return quickly and your code can do as intended. But if a thread tries to get a lock while another one already has it, the second one is blocked and can't continue until the first one releases it.

In short, surrounding some code with lock/unlock calls guarantees that only one thread will operate that part of the code with that specific lock at any given time.

What you want to do to optimize the concurrency of your code is to hold locks for as few operations as possible, during the shortest time, and with the most specificity (different locks for different data structures, even if the code is common).

Beyond this, you have to be aware of deadlocks, livelocks, priority inversion, etc. But just making sure that each shared structure has an associated lock (and is used consistently!) is a good start.

Encapsulating the lock with the shared structure, and using only access functions that enforce the lock makes it much easier to do correctly.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.