LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   How to achieve atomic increment/decrement in Linux (https://www.linuxquestions.org/questions/programming-9/how-to-achieve-atomic-increment-decrement-in-linux-781967/)

silentray 01-13-2010 09:32 AM

How to achieve atomic increment/decrement in Linux
 
Hi,

I am new to Linux programming.

Is there anyway in Linux that can achieve atomic increment/decrement for an integer variable without being interrupted? It means that the thread should not give chance for other thread to run until the increment/decrement is completed.

Please help. Many thanks.

Regards.

Sergei Steshenko 01-13-2010 09:36 AM

Try

Linux semaphore thread

in your favorite WEB search engine.

ta0kira 01-13-2010 11:17 AM

Quote:

Originally Posted by Sergei Steshenko (Post 3825193)
Try

Linux semaphore thread

in your favorite WEB search engine.

That's not atomic; the locking and unlocking are, but a number of things can reveal an intermediate state.
Kevin Barry

jf.argentino 01-13-2010 11:24 AM

Quote:

semaphore thread
I think semaphore is an oversized solution to protect an increment / decrement operation only. If you're using gcc, take a look here.

bigearsbilly 01-13-2010 12:59 PM

if you are threading you should be using mutexes.
and conditions etc.

Sergei Steshenko 01-13-2010 02:15 PM

Quote:

Originally Posted by ta0kira (Post 3825312)
That's not atomic; the locking and unlocking are, but a number of things can reveal an intermediate state.
Kevin Barry

Intermediate state of what ?

neonsignal 01-13-2010 05:47 PM

If you must have atomic operations rather than using mutexes (Knuth says that "premature optimization is the root of all evil"!), then have a look at how the kernel atomic operations are implemented in C. They are of course processor dependent, not portable.

As far as I know, the Posix API provides no way of doing atomic operations (apart from the normal semaphores etc).

ta0kira 01-13-2010 06:34 PM

Quote:

Originally Posted by Sergei Steshenko (Post 3825468)
Intermediate state of what ?

  1. lock
  2. increment (??? you might not know what happens here)
  3. unlock
That's at least 3 operations, and mutexes are optional. If by chance incrementing takes more than 1 instruction a signal handler could see it partway done, or another thread could. If, of course, the incrementation is already atomic then there's no problem in the first place, but a semaphore makes it no more atomic.
Kevin Barry

jlinkels 01-13-2010 08:03 PM

The question is badly formulated (or it is a bad question).

Code:

i--;
What difference does it make whether or not the sequence before or after the i-- is interrupted? The decrement will most likely be atomic, something like
Code:

decr [bp-16]
What is non-atomic about it?

An atomic operation usually consists of more than one operations which might not be interrupted. Like:
Code:

if (i > 0){
j++;
}

THAT is something which requires special measures if you don't want to have i changed once you made a decision. Therefor the 68000 had instructions like Test And Set, which was atomic by design.

In the example I gave above the more than one instructions, if the must be atomic, must be protected in some way. But from what?

So before any answer can given about how to achieve atomicness (sp?) we would like to know which instructions should be prevented against what.

jlinkels

neonsignal 01-13-2010 08:18 PM

Quote:

The decrement will most likely be atomic
A single processor instruction is atomic in the sense that it cannot be interrupted. However, now that multi-processor/multi-core systems are common (and complex memory caching), you have to be careful about whether the atomicity extends to the memory access. That is why the lock prefix was added to the x86 instruction set.

It is also poor practice to rely on the compiler to produce the same code in every context. There are ways of mitigating this (such as making use of 'volatile'), but it is best to keep such sensitive code inside a library of thread-aware functions, rather than sprinkled through user code.

Sergei Steshenko 01-14-2010 06:33 AM

Quote:

Originally Posted by ta0kira (Post 3825712)
  1. lock
  2. increment (??? you might not know what happens here)
  3. unlock
That's at least 3 operations, and mutexes are optional. If by chance incrementing takes more than 1 instruction a signal handler could see it partway done, or another thread could. If, of course, the incrementation is already atomic then there's no problem in the first place, but a semaphore makes it no more atomic.
Kevin Barry

I meant that the same semaphore to be used for both incrementing and reading the value. In such a case if the incrementing thread has grabbed the semaphore, the thread reading the the value being incremented will be able to read it only after the increment is complete and the semaphore is released.

I.e. I was talking about classical critical section protected by semaphore.

...

By the way, the first match in 'Yahoo' gives a link to a Qt function which implements safe increment - and that was the main point of my post.

jlinkels 01-14-2010 06:33 AM

I think the question is a bit ambiguous, the OP ask for an atomic increment/decrement while most likely he wants to protect this operation from interruption.

Mutexes or semaphores are the way to go. IIRC these functions are part of the threads library in C.

It should not be forgotten that the other thread should use the same mutexes to protect the same variable in the other thread.

Thinking about how a semaphore is decremented in a thread safe-way is a challenge in its own.

jlinkels


All times are GMT -5. The time now is 11:02 AM.