Atom code in multi-threaded app?
Author
At the moment, this is purely for self-edification. I was considering different locking mechanisms, and I came to the conclusion that the locking and unlocking routines could not be interrupted or else bad things could happen. When I looked up what a piece of code guaranteed to run uninterrupted was called, I ran into the term "atom".
My question is, how would one implement a safe locking and unlocking mechanism in C++ with or without using an "atom", and if there are good methods which do not require "atoms", what are they?
I am considering a hypothetical situation in which I would run multiple collision detection threads which incrementally run through a list of dynamic objects to check each against a static terrain quad tree.
IIRC, most multi-threadable architectures have a special "atomic" instruction.
I used to know the name of the one for x86, but I think what it did was check the value of a bit and set the bit all in one machine code instruction (or something similar).
This instruction would then be used by the mutex, semaphore and critical section implementations. So it's probable that you would need to at some time dabble in machine code.
But if you want to use one right now for your collision detecting, you're probably much better off just using something like a critical section.
It depends on your target platform(s) as to what concurrency objects are available.
I used to know the name of the one for x86, but I think what it did was check the value of a bit and set the bit all in one machine code instruction (or something similar).
This instruction would then be used by the mutex, semaphore and critical section implementations. So it's probable that you would need to at some time dabble in machine code.
But if you want to use one right now for your collision detecting, you're probably much better off just using something like a critical section.
It depends on your target platform(s) as to what concurrency objects are available.
I could be wrong, as I've not looked much, but it was my understanding that atomic operations weren't special in any real way; they're just guaranteed to take one tick of the processor (thus cannot be interrupted mid-operation by another thread).
But it largely doesn't matter, such locking mechanisms are already made by folks with far more experience than you or I, so use one (win32 threads, boost::thread, etc.)
But it largely doesn't matter, such locking mechanisms are already made by folks with far more experience than you or I, so use one (win32 threads, boost::thread, etc.)
Author
Thanks for the replies.
I've looked around a bit, and it seems I've found a solution that works well enough. If I wrap a function call in a locking mechanism, the function call would theoretically not run in more than one thread, right?
Obviously I would have to be on the lookout for deadlocks, but if this were the only shared resource, would it work?
I've looked around a bit, and it seems I've found a solution that works well enough. If I wrap a function call in a locking mechanism, the function call would theoretically not run in more than one thread, right?
Obviously I would have to be on the lookout for deadlocks, but if this were the only shared resource, would it work?
Yeah, basically if your function does:
Then you're fine as long as your lock mechanism works.
Telastyn: You're right, but it's very hard to do enough to test and enter a critical section in one tick. That's why x86 has that special instruction.
Actually, looks like there's a few ones in x86 that would do it. The one I was thinking of is BTS: Bit Test + Set.
void foo() { lock.enter(); // Do stuff here safe in the knowledge that only 1 thread can access this. lock.close();}Then you're fine as long as your lock mechanism works.
Telastyn: You're right, but it's very hard to do enough to test and enter a critical section in one tick. That's why x86 has that special instruction.
Actually, looks like there's a few ones in x86 that would do it. The one I was thinking of is BTS: Bit Test + Set.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
