C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  using volatile bools instead of mutexes when synchronizing t Goto page 1, 2, 3, 4, 5, 6  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message skoco Guest Posted: Sun Feb 15, 2004 12:10 pm    Post subject: using volatile bools instead of mutexes when synchronizing t Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Please be mercifull with critics if this idea is pure stupidity :-) Thanks a lot for some comments. skoco [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ralf Guest Posted: Mon Feb 16, 2004 12:22 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi "skoco" <skoco2002 (AT) yahoo (DOT) com> schrieb im Newsbeitrag news:d7be6dd6.0402150316.64fbaaf1 (AT) posting (DOT) google.com... Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Please be mercifull with critics if this idea is pure stupidity :-) Thanks a lot for some comments. skoco Hi, using volatile bool's as mutexes will cause some problems. For example: asking for the run condition (if( bMut == false) ) can give you the green light. But one line later can be the context switch to another thread. In the second thread the condition can be improved also, it will get also green light! But I think, there is a solution: for two threads you need two volatile bool's: b1 and b2. The first thread has to switch the variables in the order b1, b2, the second thread has to switch them in the reverse order. Between the switching there should be another check of the variables (like in the double check pattern). Ralf www.oop-trainer.de/indexp1.html [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dhruv Matani Guest Posted: Mon Feb 16, 2004 12:26 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi On Sun, 15 Feb 2004 07:10:48 -0500, skoco wrote: Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Please be mercifull with critics if this idea is pure stupidity Yes. The idea is pure stupid AFAICS! That's because there are no signle bit registers, and even it there were, I doubt that the hardware would be able to guarantee Atomic instructions on those registers for those particular instructions. You already have a lock instruction on x86. Make use of it! Regards, -Dhruv. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Peter Koch Larsen Guest Posted: Mon Feb 16, 2004 12:27 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi "skoco" <skoco2002 (AT) yahoo (DOT) com> skrev i en meddelelse news:d7be6dd6.0402150316.64fbaaf1 (AT) posting (DOT) google.com... Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) First, mutexes do not neccesarily require a "syscall", if by that you mean a call to the kernel. Quote: I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? There could be many kinds of problems, so dont. Also, your reasoning above is not valid. Even if a variable is declared volatile, nothing prevents it from being being read into a register. Quote: Please be mercifull with critics if this idea is pure stupidity :-) Thanks a lot for some comments. skoco You could visit comp.programming.threads and have a look one of the many threads related to your question. The short answer is that you should use some library (pthreads/boost/whatever) and rely on it in order to get your mutexes. Kind regards Peter [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Graeme Prentice Guest Posted: Mon Feb 16, 2004 12:34 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi On 15 Feb 2004 07:10:48 -0500, skoco wrote: Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Please be mercifull with critics if this idea is pure stupidity You can't just read a bool, check for false, then set it true and hope that you're the only thread that then thinks it owns the flag. If a thread switch occurs between reading the bool and setting it true, you can get two threads both thinking they "own" the flag. You need a non-interruptible "test and set" instruction. This is sort of what interlocked- increment does on windows. On a windows or unix platform you are better to use the operating system supplied mutex. On an embedded platform, if there is no "test and set" instruction available, you can possibly disable interrupts for a short time, to ensure no thread switch occurs between the read and the write. Normally, a mutex would have additional functionality that when the task has to wait on the mutex, it goes into a "semaphore wait queue" rather than into the run queue, and when the semaphore gets signalled, the task is woken up. This ensures that all tasks that wait on the same semaphore, eventually get a turn. Regarding volatile, check my recent question in this newsgroup. Graeme [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Michael Tiomkin Guest Posted: Mon Feb 16, 2004 12:36 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi [email]skoco2002 (AT) yahoo (DOT) com[/email] (skoco) wrote in message news:<d7be6dd6.0402150316.64fbaaf1 (AT) posting (DOT) google.com>... Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Please be merciful with critics if this idea is pure stupidity The problem is that you cannot safely hold the value in a register before changing and writing it to the memory in the same thread: another thread can try to update the memory at the same time. Safe and efficient implementation of mutex without system calls needs an atomic test-and-set operation that is issued directly on memory. Usually, this operation doesn't exist in high level languages. BTW, you can easily do this with inlined assembly. There is only a perfomance problem - in case that the request of your thread is not satisfied, you'll need to use busy waiting with sleep and test&set loop. The standard system semaphore object would suspend your thread and put it in a waiting queue instead of busy wait. A book on realtime or OS programming can be helpful in this case. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ingo Berg Guest Posted: Mon Feb 16, 2004 11:12 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi Dont do that! It wont work because checking the flag and resetting it requires more then one instruction for the processor. So theoretically the execution could switch to another thread right after the first one has determined the flag is not set but before it could reset it. A second thread checking that flag would not recognize that a flag change is about to happen by the first threat. Hence this threat could enter the function too. It does not matter if the varible is volatile since the first threat was disrupted before it was able to change its value. What makes this approach even worse is that it might look like it works because most times the thread change will not take place at this critical point in time. Errors that originate from such mistakes are very hard to detect. Kind regards, Ingo [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Richter Guest Posted: Mon Feb 16, 2004 11:15 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi Hi, Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Please be mercifull with critics if this idea is pure stupidity What you need for mutexes is some kind of atomic "test and set" operation, or an atomic "increment and test" operation. "atomic" in the sense of that it cannot be interrupted by other processes, threads or (possibly) CPUs in a multi-processor system. volatile is not sufficient to guarantee that. You *might* get away with a mutex count (increment/decrement/test operation) that is atomic on some popular platforms, (i.e. "if (++i ==0) { }") but that's outside of the scope of C++ that doesn't give you *any* guarantee about atomicity of these operations. So long, Thomas [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Marco Oman Guest Posted: Mon Feb 16, 2004 11:17 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi On 15 Feb 2004 07:10:48 -0500, skoco <skoco2002 (AT) yahoo (DOT) com> wrote: Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Please be mercifull with critics if this idea is pure stupidity No need of being mercyful, since I have been bitten by a bug born from the same idea. Said that what I post is more another question rather than an answer. On a dual processor machine (with shared memory architecture) one may end up with one thread writing (from processor A) on actual memory and the other one (which happens to use always processor B) reading from its cache (and so missing the shared memory update). If you want to avoid system calls on x86 architectures there are some instruction that implememnt some sort of interlocked memory access and so are very fast. Win32 has the functions Interlocked* that wrap them, they have also linux counterpart. Now the question: can the proposed approach work on a single processor machine? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Turner Guest Posted: Mon Feb 16, 2004 11:22 pm    Post subject: Re: using volatile bools instead of mutexes when synchronizi Hi Quote: I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I think you'll find that this is impossible. At the very least, you need an atomic test-and-set primitive, which you don't have access to from C++ (because not all platforms have such a thing). I'm afraid you're stuck with that syscall . Try comp.programming.threads for more information about synchronization. Regards David Turner [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top v Guest Posted: Tue Feb 17, 2004 11:15 am    Post subject: Re: using volatile bools instead of mutexes when synchronizi hello, well not really an answer, and not really encoraging to do it the way i do, but i rarely protect bool variables from being accessed by concurrent threads. e.g. class thread { ..... public: void run() { while(!stop) { ... } } void do_stop() { stop=true; } }; correct me if wrong (i am no assemby guru), but in the worst case (while(!stop) and stop=true runing concurrently) what could happen???? a) stop is in memory (not in a register) and while(!stop) reads the old value although it has been changed in the register and is being written back shortly after, loop one more time. b) stop is in register, stop=true needs 2 cycles, while(!stop) reads the incomplete value and loops one more time assuming that bool(false) is represented as all bits 0, and bool(true) any bit being set to 1 independet of the length. bye vlado "skoco" <skoco2002 (AT) yahoo (DOT) com> schrieb im Newsbeitrag news:d7be6dd6.0402150316.64fbaaf1 (AT) posting (DOT) google.com... Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Please be mercifull with critics if this idea is pure stupidity [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Daniel Pfeffer Guest Posted: Tue Feb 17, 2004 11:16 am    Post subject: Re: using volatile bools instead of mutexes when synchronizi "skoco" <skoco2002 (AT) yahoo (DOT) com> wrote Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) I haven't tried it yet (i will soon), but do you think there could be some kind of problem? volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? Your understanding of 'volatile' is correct, but there are a few problems with this approach: 1. If the 'bool' is owned by a different thread your code must go into a busy loop, sampling the 'bool' every so often. This wastes CPU resources. 2. Scheduling algorithms that provide a priority boost when a thread is suffering from "CPU time starvation" will not work. (e.g. some O/Ses may temporarily raise the priority of a thread - within limits - if it hasn't received CPU resources in the last X seconds). 3. The system is not expandable to multiple locks (see the Wait ForMultipleObjects() API in Win32). These locks are sometimes unavoidable. 4. The O/S typically monitors the resources acquired by the various threads and will release a mutex held by a thread that crashes. This will not happen with your 'bool'. To summarise, there are very good reasons why mutexes are part of the O/S. Use the O/S constructs, and don't re-invent the wheel. HTH, Daniel Pfeffer [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Tue Feb 17, 2004 11:20 am    Post subject: Re: using volatile bools instead of mutexes when synchronizi [email]skoco2002 (AT) yahoo (DOT) com[/email] (skoco) wrote in message news:<d7be6dd6.0402150316.64fbaaf1 (AT) posting (DOT) google.com>... Quote: I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) If you are concerned with synchronizing between threads, it doesn't work. Quote: I haven't tried it yet (i will soon), but do you think there could be some kind of problem? Sure. Like the fact that different threads will see different values at different times. Quote: volatile specifier ensures that bool variable will be always read into registers only at the time it's needed, so holding the variable in register and changing its value in another thread shouldn't happen, am I right? It depends on how the implementation defines access to a volatile. Most implementations today don't define it in a way that can be useful for communicating between threads. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jerry Feldman Guest Posted: Tue Feb 17, 2004 11:28 am    Post subject: Re: using volatile bools instead of mutexes when synchronizi On 16 Feb 2004 07:34:34 -0500 Graeme Prentice <invalid (AT) yahoo (DOT) co.nz> wrote: Quote: Normally, a mutex would have additional functionality that when the task has to wait on the mutex, it goes into a "semaphore wait queue" rather than into the run queue, and when the semaphore gets signalled, the task is woken up. This ensures that all tasks that wait on the same semaphore, eventually get a turn. While this is a bit off topic, this is not entirely true, and depends on the specic mutex implementation. The bottom line is that if the mutex is unlocked, the ovderhead should be very low. There is the POSIX pthread_mutex_trylock() function that returns 0 if the mutex is unlocked and EBUSY when locked. Depending on the implementation, the POSIX fast mutex should have very low overhead, and to do better, you could implement your own in assembler. Neither C++ nor C have atomic variables as part of the standard. -- Jerry Feldman <gaf-nospam-at-blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bill Wade Guest Posted: Tue Feb 17, 2004 11:33 am    Post subject: Re: using volatile bools instead of mutexes when synchronizi [email]skoco2002 (AT) yahoo (DOT) com[/email] (skoco) wrote in message news:<d7be6dd6.0402150316.64fbaaf1 (AT) posting (DOT) google.com>... Quote: Hello! I was thinking about a interesting thing of replacing mutexes (which obviously needs some kind of syscall) with volatile variables (bool will do all needed functionality) The standard doesn't make any promises (neither do I). However you will want to use volatile sig_atomic_t instead of volatile bool. A problem with bool is that it may be smaller than the machine's word size, so a bool variable may share a word with another variable. When the two variables are written (one from each thread) one of the writes may be lost, because a write is implemented as (load word, modify bool, write word) and this may not be atomic. In most cases you'll want to have only one writer of the variable. Of course you don't get the blocking that a mutex provides. YMMV, HTH [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3, 4, 5, 6  Next Page 1 of 6   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.