boost condition_variable internals
I need to know that boost does not use any kind of locking, mutex or semaphore mechanism within the boost::condition_variable class. I don't know where it is in source, or I would check to make certain. Can someone provide me a yes no verification?
On Fri, Jan 24, 2014 at 08:46:23AM -0600, Kenneth Adam Miller wrote:
I need to know that boost does not use any kind of locking, mutex or semaphore mechanism within the boost::condition_variable class. I don't know where it is in source, or I would check to make certain. Can someone provide me a yes no verification?
The source code for a library is separated into two locations: boost_1_xx_y/boost/name boost_1_xx_y/libs/name/src The former is the public headers and the latter is the sources and headers used to build the compiled parts of some libraries. As for Boost.Thread, I would start at the headers, looking at the top-level header for the feature you're interested in. In the case of condition_variable, it immediately branches into win32 and pthread. At a quick glance, they may or may not have internal mutexes and semaphores based on things like if the platform does interruption. All in all it seems like a moot question without any other information, considering that condition_variable by definition requires you to pass in locks anyway when you wait on one. -- Lars Viklund | zao@acc.umu.se
Ah yeah, I found the source location just a bit after sending that and saw
about what condition_variable uses internally after I looked at it. I can
use locks, but I'm restricted to using locks that are from the pin
threading api, so any locks that come from pthreads or windows are the ones
that I have to avoid.
I don't know if you saw my ealier message, but I have a complex set of
needs that I have to satisfy and I can't have any library that I use call
upon those non-pintool-api utilities (locks, thread management of any
kind). They have to be routed through the pintools api. So I need help
determining what will and won't work that architecture.
In that case, I've found boost's lockfree queue; now I need to be able to
efficiently poll on message recipients (sort of what condition variables
provided). I'm using all of these facilities rather than simple message
passing because I'm not sure that I can learn openMPI fast enough for my
deadline.
On Fri, Jan 24, 2014 at 9:38 AM, Lars Viklund
On Fri, Jan 24, 2014 at 08:46:23AM -0600, Kenneth Adam Miller wrote:
I need to know that boost does not use any kind of locking, mutex or semaphore mechanism within the boost::condition_variable class. I don't know where it is in source, or I would check to make certain. Can someone provide me a yes no verification?
The source code for a library is separated into two locations: boost_1_xx_y/boost/name boost_1_xx_y/libs/name/src
The former is the public headers and the latter is the sources and headers used to build the compiled parts of some libraries.
As for Boost.Thread, I would start at the headers, looking at the top-level header for the feature you're interested in. In the case of condition_variable, it immediately branches into win32 and pthread.
At a quick glance, they may or may not have internal mutexes and semaphores based on things like if the platform does interruption.
All in all it seems like a moot question without any other information, considering that condition_variable by definition requires you to pass in locks anyway when you wait on one.
-- Lars Viklund | zao@acc.umu.se _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 1/24/2014 9:51 AM, Kenneth Adam Miller wrote:
Ah yeah, I found the source location just a bit after sending that and saw about what condition_variable uses internally after I looked at it. I can use locks, but I'm restricted to using locks that are from the pin threading api, so any locks that come from pthreads or windows are the ones that I have to avoid. You could add an implementation of the mutex and condition_variable classes that use the "pin api", just as it has separate files now for pthreads and Win32. With the classes now being part of the C++ standard, such would be expected for any "api".
participants (3)
-
John M. Dlugosz -
Kenneth Adam Miller -
Lars Viklund