Skip to main content
gamedev.net
🔒 Locked

Atom code in multi-threaded app?

Started by Guru2012 3 replies 900+ views
Original Post
Guru2012
Guru2012
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.
Skarsha
Skarsha
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.
Telastyn
Telastyn
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.)
Guru2012
Guru2012
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?
Skarsha
Skarsha
Yeah, basically if your function does:

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.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.