How can any state critical system (I have never heard of one otherwise) be dependent on something that works "spuriously"?
I guess I need to search for a new concept or assume spuriously is just a technical nit pick incase its impossible to make the lock in the first place due to some lower level fault. If "spuriously"ness occurs which must be a pretty minimal odd I will hit program failure and safely shut down anyway. I am worried by "spuriousity" thats like saying it may become sentient at it chose to reject a request when it chooses. I think the odds are minimal. Is there documentation on this pehnomenon and its frequnecy of occurence?
Boost shared_mutex is there a total mutex's sharing method I can call?
Author
And on with google the results are in on what it might mean.
Spurious \Spu"ri*ous\ (sp[=u]"r[i^]*[u^]s), a. [L. spurius.]
1. Not proceeding from the true source, or from the source
pretended; not genuine; counterfeit; false; adulterate.
[1913 Webster]
spu·ri·ous (spyr-s)
adj.
1. Lacking authenticity or validity in essence or origin; not genuine; false.
Does it mean if the system is penetrated by some means of aggressive attack perhaps? it assumes that its from a source outside of the ordinary program so I think its pretty improbable. Still its a key thing to account for thank you for the heads up on that factor!
Perhaps it refers to the task manager shutting down the program or the compile overriding the action? it sounds like abit of a mute point as anything can be supriously stepped out of by that means.
Spurious \Spu"ri*ous\ (sp[=u]"r[i^]*[u^]s), a. [L. spurius.]
1. Not proceeding from the true source, or from the source
pretended; not genuine; counterfeit; false; adulterate.
[1913 Webster]
spu·ri·ous (spyr-s)
adj.
1. Lacking authenticity or validity in essence or origin; not genuine; false.
Does it mean if the system is penetrated by some means of aggressive attack perhaps? it assumes that its from a source outside of the ordinary program so I think its pretty improbable. Still its a key thing to account for thank you for the heads up on that factor!
Perhaps it refers to the task manager shutting down the program or the compile overriding the action? it sounds like abit of a mute point as anything can be supriously stepped out of by that means.
No, it just means that OSs aren't reliable about putting threads to sleep until a condition is met, so you've got to enforce this yourself. It might wake up when the condition is met, or it might just wake up anyway (i.e. it means there are false-positives in the system, but not false-negatives).
You shouldn't just pretend it's not going to happen, or that it doesn't matter if it does happen occasionally.
This is one reason why it's designed so you must acquire a lock before waiting (and automatically acquire again after waiting) -- you can use that lock to protect an actual variable that you use to decide if waiting is over or not.
Think of wait like an optimisation-hint, but not a strong guarantee. You could just write a spin loop that repeatedly locks a mutex, checks the variable and unlocks the mutex -- but wait is an optimisation that tries to give spare cycles to the OS.
You shouldn't just pretend it's not going to happen, or that it doesn't matter if it does happen occasionally.
This is one reason why it's designed so you must acquire a lock before waiting (and automatically acquire again after waiting) -- you can use that lock to protect an actual variable that you use to decide if waiting is over or not.
Think of wait like an optimisation-hint, but not a strong guarantee. You could just write a spin loop that repeatedly locks a mutex, checks the variable and unlocks the mutex -- but wait is an optimisation that tries to give spare cycles to the OS.
Author
I will design a means of cycling until it is met so long as notify one is garunteed to notify something if there is a thread in a wait state this shouldn't be a show stopping issue.
I think I have gathered enough info to continue. Still curious why there wasn't a get total_count method to begin with for the condition variable it seems like a sensible thing to have if it can be shared.
I think I have gathered enough info to continue. Still curious why there wasn't a get total_count method to begin with for the condition variable it seems like a sensible thing to have if it can be shared.
Quote:Original post by EnlightenedOneI've read back over the thread, and the solution to the above issue seems to be: don't unlock your mutex before calling wait - then the counter, the boolean, the call to wait, and the call to notify are all atomic/mutually-exclusive.
The issue is that the notify function can notify when the boolean is changed before the other thread actually goes into the wait mechanism and is added to the list of threads waiting on the semaphore. I cant obviously change the values in the midst of going into wait with a timed lock because on wait any timed processes the thread had going are also set to wait.
void waitUntilAllReady() { lock_guard lock(mutAccessData); while (boolIsSceneReady == false) { intThreadsCaughtCountPost++; multiThreadLinkReady.wait(mutAccessData); intThreadsCaughtCountPost--; } } void wakeUpIfAllReady() { lock_guard lock(mutAccessData); if (intThreadsCaughtCountPost >= TOTALTHREADSLOADINGSCENE) { multiThreadLinkReady.notify_all(); boolIsSceneReady = true; } }
Author
You lock on the wait function your logic then calls this.
lock_guard lock(mutAccessData);
The bold line will never be passed as deadlock occurs and your program is frozen dead. mutAccessData is not a shared mutex.
void wakeUpIfAllReady() { lock_guard lock(mutAccessData); if (intThreadsCaughtCountPost >= TOTALTHREADSLOADINGSCENE) { multiThreadLinkReady.notify_all(); boolIsSceneReady = true; } }lock_guard lock(mutAccessData);
The bold line will never be passed as deadlock occurs and your program is frozen dead. mutAccessData is not a shared mutex.
There's no deadlock and the mutex doesn't need to be shared for the purposes of the counter and the boolean. When you call wait, the mutex is unlocked for the duration of the wait:
A) All your worker threads have called wait.
B) Any of your worker threads haven't called waitUntilAllReady yet (in which case the if will fail and wakeUpIfAllReady will return with no effect).
Quote:Atomically call lock.unlock() and blocks the current thread.^This is the key to the wait function - when you call wait, the unlock and the actual sleeping are one atomic operation, so you can ensure the boolean isn't set to true at the same time as going into a wait. The boolean can only be set to true while all threads are waiting. The line you marked bold won't be passed unless:
When the thread is unblocked (for whatever reason - i.e. spuriously or not), the lock is reacquired by invoking lock.lock() before the call to wait returns. The
A) All your worker threads have called wait.
B) Any of your worker threads haven't called waitUntilAllReady yet (in which case the if will fail and wakeUpIfAllReady will return with no effect).
Author
ah that does change the game plan. Thanks for your input sorry I was abit slow to catch on there I had the feeling my intention had been lost in my explanation but this is definetely useful! I will update you on how things go when I rewrite this class.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
