How to achieve atomic increment/decrement in Linux
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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).
Last edited by neonsignal; 01-13-2010 at 05:51 PM.
increment (??? you might not know what happens here)
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
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,195
Rep:
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.
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.
Last edited by neonsignal; 01-13-2010 at 08:24 PM.
increment (??? you might not know what happens here)
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.
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,195
Rep:
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.