surprising accessability of free locking functions for mutex

Having followed the discussion about the availability of direct locking of mutexes, I am somewhat surprised that there are free functions available for this purpose. Is this by intent? Is using them simply bad practice? I.e.: boost::mutex m1; boost::detail::thread::lock_ops<boost::mutex>::lock(&m1); is e legal statement. (And indeed is locking the mutex.) Yes I've seen the "detail". Does this imply: Anything that is detail definitely should not go into user programs? I am asking this not for pure 'academic' reasons. What I am trying to do is to find out whether it is possible to write a small wrapper over the existing classes to support a kind of cancellability for my threads, until the "real thing" will be available. Thank you. Roland

"Roland Schwarz" <roland.schwarz@chello.at> wrote in message news:418A2783.5010703@chello.at...
Having followed the discussion about the availability of direct locking of mutexes, I am somewhat surprised that there are free functions available for this purpose.
Is this by intent? Is using them simply bad practice?
I.e.:
boost::mutex m1; boost::detail::thread::lock_ops<boost::mutex>::lock(&m1); is e legal statement. (And indeed is locking the mutex.)
Yes I've seen the "detail". Does this imply: Anything that is detail definitely should not go into user programs?
Yes. In my understanding, anything in the detail namespace is an implementation detail, is not part of the public interface, and is subject to change without notice. Also, it very likely would be different in an alternate implementation that used the Boost public interfaces.
I am asking this not for pure 'academic' reasons. What I am trying to do is to find out whether it is possible to write a small wrapper over the existing classes to support a kind of cancellability for my threads, until the "real thing" will be available.
Thank you.
Roland
Mike
participants (2)
-
Michael Glassford
-
Roland Schwarz