You provide gun, I provide foot.
Quoting from http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.mutexes "Many C++ threading libraries use a pattern known as Scoped Locking[SchmidtStalRohnertBuschmann] to free the programmer from the need to explicitly lock and unlock mutex objects. With this pattern, a Lock concept is employed where the lock object's constructor locks the associated mutex object and the destructor automatically does the unlocking. The Boost.Threads library takes this pattern to the extreme in that Lock concepts are the only way to lock and unlock a mutex object: lock and unlock functions are not exposed by any Boost.Threads mutex objects. This helps to ensure safe usage patterns, especially when code throws exceptions." Unfortunately, I actually WANT to shoot myself in the foot this time and Boost.Threads won't let me!!! I can understand ENCOURAGING users to write safe code, but forcing them to is outright fascist! My problem is that I have existing code which I would like to make more portable by using Boost.Threads. Now, this wouldn't be a problem except for the fact that I'm (effectively) dealing w/ a COM object that already has its interface defined. There must be millions of lines of code which won't be able to get a minor face-lift because "lock and unlock functions are not exposed". Since when is ensuring safe usage more important than providing common functionality? Ugh, Dino
C. Michailidis wrote:
Quoting from http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.mutexes
"Many C++ threading libraries use a pattern known as Scoped Locking[SchmidtStalRohnertBuschmann] to free the programmer from the need to explicitly lock and unlock mutex objects. With this pattern, a Lock concept is employed where the lock object's constructor locks the associated mutex object and the destructor automatically does the unlocking. The Boost.Threads library takes this pattern to the extreme in that Lock concepts are the only way to lock and unlock a mutex object: lock and unlock functions are not exposed by any Boost.Threads mutex objects. This helps to ensure safe usage patterns, especially when code throws exceptions."
Unfortunately, I actually WANT to shoot myself in the foot this time and Boost.Threads won't let me!!! I can understand ENCOURAGING users to write safe code, but forcing them to is outright fascist!
Read the above carefully... It doesn't say there aren't lock/unlock calls. Only that mutexes don't provide them. You are free to shoot yourself by manually locking and unlocking "Locks". Which will lock/unlock the associated mutex. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Read the above carefully... It doesn't say there aren't lock/unlock calls. Only that mutexes don't provide them. You are free to shoot yourself by manually locking and unlocking "Locks". Which will lock/unlock the associated mutex.
But there is no class which models the Lock concept, or is there? Markus
Markus Schöpflin wrote:
Rene Rivera wrote:
Read the above carefully... It doesn't say there aren't lock/unlock calls. Only that mutexes don't provide them. You are free to shoot yourself by manually locking and unlocking "Locks". Which will lock/unlock the associated mutex.
But there is no class which models the Lock concept, or is there?
There is.. http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.Mutex In that section you'll see that there's a M::scoped_lock type that implements the ScopedLock concept. And if you continue reading you can see that each mutex variant has such a type to correspond to the type of Lock concept they support. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Markus Schöpflin wrote:
Rene Rivera wrote:
Read the above carefully... It doesn't say there aren't lock/unlock calls. Only that mutexes don't provide them. You are free to shoot yourself by manually locking and unlocking "Locks". Which will lock/unlock the associated mutex.
But there is no class which models the Lock concept, or is there?
There is..
http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.Mutex
In that section you'll see that there's a M::scoped_lock type that implements the ScopedLock concept. And if you continue reading you can see that each mutex variant has such a type to correspond to the type of Lock concept they support.
Pardon me for being dense, but I don't see what you are referring to on this page. In Table 10.11, the Lock concept doesn't have any model. AFAIK, you can only work with dynamically allocated locks as Dave outlined in another post. But OTOH, perhaps I'm just beeing blind when reading the page. Markus
Markus Schöpflin wrote:
Pardon me for being dense, but I don't see what you are referring to on this page. In Table 10.11, the Lock concept doesn't have any model. AFAIK, you can only work with dynamically allocated locks as Dave outlined in another post. But OTOH, perhaps I'm just beeing blind when reading the page.
Maybe I'm misunderstanding what you are trying to do.. In that table (10.11) it is true that Lock doesn't have a model, but it's refinements do have models. What prevents you from using say, the boost::mutex::scoped_lock model? (Which has the lock/unlock calls.) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Markus Schöpflin wrote:
Pardon me for being dense, but I don't see what you are referring to on this page. In Table 10.11, the Lock concept doesn't have any model. AFAIK, you can only work with dynamically allocated locks as Dave outlined in another post. But OTOH, perhaps I'm just beeing blind when reading the page.
Maybe I'm misunderstanding what you are trying to do.. In that table (10.11) it is true that Lock doesn't have a model, but it's refinements do have models. What prevents you from using say, the boost::mutex::scoped_lock model? (Which has the lock/unlock calls.)
Bah, I just realized that I indead was a little slow-witted when reading that page. Of course scoped_lock has lock() and unlock() calls. I didn't really realize that refinement implies that the interface of the Lock concept is also present in the ScopedLock concept. Sorry for the noise. Markus
Markus Schöpflin wrote:
Rene Rivera wrote:
Markus Schöpflin wrote:
But there is no class which models the Lock concept, or is there?
In that section you'll see that there's a M::scoped_lock type that implements the ScopedLock concept. And if you continue reading you can see that each mutex variant has such a type to correspond to the type of Lock concept they support.
Pardon me for being dense, but I don't see what you are referring to on this page. In Table 10.11, the Lock concept doesn't have any model. AFAIK, you can only work with dynamically allocated locks as Dave outlined in another post. But OTOH, perhaps I'm just beeing blind when reading the page.
See http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.lock-mo... If locks had no models, Dave's suggestions wouldn't work either. In fact, mutexes would be useless. Jonathan
Jonathan Turkanis wrote:
Pardon me for being dense, but I don't see what you are referring to on this page. In Table 10.11, the Lock concept doesn't have any
See
http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.lock-mo... Ooops, sorry. I see you already found that page. So I'm not sure what the problem is.
Jonathan
C. Michailidis <dinom@balstonresearch.com> wrote:
Unfortunately, I actually WANT to shoot myself in the foot this time and Boost.Threads won't let me!!! I can understand ENCOURAGING users to write safe code, but forcing them to is outright fascist!
take a look at threading functionality available in my project http://b.kozicki.pl/rcpt/ If you find anything useful there, I can publish selected parts under Boost license (it is CPL now) B.
"C. Michailidis" <dinom@balstonresearch.com> writes:
Quoting from http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.mutexes
"Many C++ threading libraries use a pattern known as Scoped Locking[SchmidtStalRohnertBuschmann] to free the programmer from the need to explicitly lock and unlock mutex objects. With this pattern, a Lock concept is employed where the lock object's constructor locks the associated mutex object and the destructor automatically does the unlocking. The Boost.Threads library takes this pattern to the extreme in that Lock concepts are the only way to lock and unlock a mutex object: lock and unlock functions are not exposed by any Boost.Threads mutex objects. This helps to ensure safe usage patterns, especially when code throws exceptions."
Unfortunately, I actually WANT to shoot myself in the foot this time and Boost.Threads won't let me!!! I can understand ENCOURAGING users to write safe code, but forcing them to is outright fascist!
Nobody's forcing you to use the library ;-)
My problem is that I have existing code which I would like to make more portable by using Boost.Threads. Now, this wouldn't be a problem except for the fact that I'm (effectively) dealing w/ a COM object that already has its
You can dynamically allocate lock objects, or you can dynamically construct them using boost::optional. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
Bronek Kozicki -
C. Michailidis -
David Abrahams -
Jonathan Turkanis -
Markus Schöpflin -
Rene Rivera