RE: Yet more on boost.threads

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-09-06 16:19:26

From: "Peter Dimov" <pdimov_at_[hidden]>

>condition.cpp does not compile when the macro NOMINMAX is not defined.

I'll add the macro before the includes.

>This program:
>
>#include <iostream>
>#include <boost/bind.hpp>
>#include <boost/thread/mutex.hpp>
>#include <boost/thread/thread.hpp>
>#include <boost/thread/tss.hpp>
>
>static boost::mutex m;
>static boost::thread_specific_ptr<int> p;
>
>void print(int n)
>{
>  p.reset(new int(n));
>  boost::mutex::scoped_lock lock(m);
>  std::cout << n << '\n';
>}
>
>int main()
>{
>  for(int i = 0; i < 8; ++i)
>  {
>    boost::thread(boost::bind(print, i));
>  }
>}
>
>sometimes prints 1, 2, ..., 7 (note absence of 0) and sometimes locks up my
>machine. (I'm using MSVC.) This happens only in Release builds, not in
>Debug; I suspect that 0 is not printed because the catch(...) handler in
>thread.cpp eats the access violation. The problem is probably in call_once.

What access violation?  I also don't see any use of call_once in the above?  
This is very similar to code used in the test harness, which passes for me 
in both Debug and Release (the one difference being the use of boost::bind, 
which I don't suspect as a problem).  This perplexes me.  I'll have to try 
it out myself later and see if I can diagnose any errors.

Bill Kempf

--
Peter Dimov
Multi Media Ltd.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp