Synchronisation and shared mutex's Get total_count

[dominicstreeter@…]

Hey there I wish to create what is in essence a barrier but with the capacity to flexibly dictate how many threads are in the barrier. The problem is synchronising.

Here is an example of the problem that shows I need to get the total count of threads accessing the shared total_count variable atomically from the boost library. I would like to know if there is a reason this is not implemented.

Here are some variables to demonstrate the issue.

boost::condition_variable_any multiThreadLinkReady;

boost::shared_mutex smutDependancyThreadCustomBarrierReady;

bool boolIsSceneReady;

Run by a management thread

void wakeUpIfAllReady() {

mutAccessData.lock();

if (intThreadsCaughtCountPost >= TOTALTHREADSLOADINGSCENE) {

if (Here I need to the total count to also equal the Constant TOTALTHREADSLOADINGSCENE to garuntee every thread wakes up in a one time call to notify all of them into the next stage)

multiThreadLinkReady.notify_all();

boolIsSceneReady = true;

}

mutAccessData.unlock();

}

Run by every thread but the management thread relating to this data

void waitUntilAllReady() {

mutAccessData.lock();

if (boolIsSceneReady == false) {

intThreadsCaughtCountPost++;

mutAccessData.unlock();

The thread is set to frozen to be awoken on the next line when the class is ready. It possible for this to not be set before the other thread calls notify all! multiThreadLinkReady.wait(smutDependancyThreadCustomBarrierReady);

So we can reuse this on the next level loaded we need to decrement the counter. mutAccessData.lock();

intThreadsCaughtCountPost--;

mutAccessData.unlock();

} else {

mutAccessData.unlock();

}

}

There is no way of avoiding using interrupts when using the available barrier mechanism with a complex system involving alot of states this is not always desirable. If a thread were to fail and you needed to bail the other threads out of the barrier class you need to do alot more than if you can use a conditional variable like this and get the total threads that are actively waiting, creating a flexible barrier.

[dominicstreeter@…]

I have written into the Boost file "condition_variable.hpp" a function to perform the correction. Details on this can be found easily here.

​http://www.gamedev.net/community/forums/topic.asp?topic_id=584562

Thank you for your time

EnlightenedOne

[dominicstreeter@…]

I wish to close this ticket on the grounds that the above code is flawed and a work around the problem faced here requires a seperate class to encapsulate a count of the total threads being used. Although there is no method for getting the total threads locked in a barrier from the class you can encapsulate this functionality in your own class outside of a barrier class and pass in the expected total threads to be waiting from there.

To explain what the barrier class that encapsulates/replaces this mechanism actually ended up looking like here is a rough abstract of my working barrier.

boost::mutex mutAccessData;

boost::condition_variable_any multiThreadLink;

int intThreadsCaughtCount;

You pass in the number of threads registered to be waiting with the scene if they are all waiting on the barrier you wake them up and return true signalling success to a managing thread that might be waiting for all of them to be at the barrier.

bool getWakeUpIfAllReady(int intThreadsHandledByObject) {

bool boolIsAwoken;

mutAccessData.lock();

if (intThreadsCaughtCount == intThreadsHandledByObject) {

multiThreadLink.notify_all();

boolIsAwoken = true;

} else {

boolIsAwoken = false;

}

mutAccessData.unlock();

return boolIsAwoken;

}

This is called by threads that need to wait until they are woken up.

void waitUntilAllReady() {

mutAccessData.lock();

intThreadsCaughtCount++;

multiThreadLink.wait(mutAccessData);

intThreadsCaughtCount--;

mutAccessData.unlock();

}

There were one or two scenarios where the rewritten get total threads might be useful for handling complex state logic for a shutdown during an erroneous event; however even that use has alternate work arounds which I have used now. Therefore I wish to retract my ticket.

Perhaps a boost class to encapsulate this behaviour might be of value? If not this would be a useful exercise to do for an example in the boost documentation on threading for newcomers. Anyway thank you for your time :)

[viboes]

Replying to dominicstreeter@…:

There were one or two scenarios where the rewritten get total threads might be useful for handling complex state logic for a shutdown during an erroneous event; however even that use has alternate work arounds which I have used now. Therefore I wish to retract my ticket.

Perhaps a boost class to encapsulate this behaviour might be of value? If not this would be a useful exercise to do for an example in the boost documentation on threading for newcomers. Anyway thank you for your time :)

Hi,

It would be great if you may write the text to be added to the tutorial.

Vicente

[viboes]

Closed as requested.