Disabling synchronization in Boost.Thread
Hi, Is there some easy way to disable all of the synchronization primatives in Boost.Thread, or in other words, make them all no-ops? I have written some generic code to be used in both singlethreaded and multithreaded environments, and it would be convenient for me to simply be able to 'switch off' synchronization when I know that I am in a singlethreaded environment, without having to uglify my code with ifdef's or similar. Simply disabling threads in Boost seems to cause synchronization primatives to fail to compile at all. Aaron
An interesting idea, and one that's almost certainly possible, but it would probably involve considerable uglification of the Boost.Thread code with ifdefs or some other mechanism, and possibly other problems. Nonetheless, it might be worth considering if enough people need it. In the mean time, you might consider writing your own mutex, lock etc. wrapper classes that use the Boost.Thread library for their implementation. This has the advantage that you can implement the feature you requested as well as being able to adjust the interfaces to your own needs, modify the implementation without modifying a lot of code, etc. Mike Aaron W. LaFramboise wrote:
Hi,
Is there some easy way to disable all of the synchronization primatives in Boost.Thread, or in other words, make them all no-ops? I have written some generic code to be used in both singlethreaded and multithreaded environments, and it would be convenient for me to simply be able to 'switch off' synchronization when I know that I am in a singlethreaded environment, without having to uglify my code with ifdef's or similar. Simply disabling threads in Boost seems to cause synchronization primatives to fail to compile at all.
Aaron
(Michael Glassford
An interesting idea, and one that's almost certainly possible, but it would probably involve considerable uglification of the Boost.Thread code with ifdefs or some other mechanism, and possibly other problems. Nonetheless, it might be worth considering if enough people need it.
In my oppinion this depends on what one understands by "ugly". I think it is "ugly" to have a threading library in non threading mode?!! I don't think that it is just an "optimization" for the single threaded case but a change of semantics, when used directly on the synchronization primitives. On the other hand I think it is fine to have a user (intermediate) library that "cleanly" #ifdefs the fact that the threading library (synchronization) is not available. In that case the semantics of my library is not changed, but optimized for the single threaded case. Just my 5 cents... Roland
participants (3)
-
Aaron W. LaFramboise
-
Michael Glassford
-
Roland