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 <zao@acc.umu.se> wrote:
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