RE: [Boost-users] RE: Boost thread problem
Hi, Thanks for help, On a Linux box I have to link against libc_r too? Probably yes, but could you confirm this? Thanks for help, Pshemek -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of C. Michailidis Sent: 15 April 2005 00:02 To: boost-users@lists.boost.org Subject: [Boost-users] RE: Boost thread problem
It seems the usage of the vector cases problems with the multithreaded
programs on the multiprocessor machines.
I have changed it to queue and the bug has been resolved. I cannot reproduce it now.
Huh, that's interesting! I suppose it may no longer be a major issue for you then (even though vectors and queues have different algorithms under the hood). Because you mentioned that the problem seems to be limited to true SMP systems, I tried your code again (this time on a dual cpu system) and I still couldn't reproduce it. I must admit that the process didn't seem to bounce between cpus though, so perhaps something is lost in the shuffle in that regard. The dual cpu system was configured similarly to the first machine that I tried it on (FreeBSD 5.3 + boost 1.32.0_2). The first machine (although not a 'true' smp system) is using hyperthreading w/ an SMP kernel so as far as the OS is concerned it too is a multiprocessor machine. If you still want to isolate the problem that you *were* having (using vector) then you may be interested in the details of thread-safe CRTs. The "-lc_r" indicates that (on FreeBSD) the re-entrant C library (i.e. thread-safe) should be linked against. On Windows I believe the analog is called something like 'msvcrtmt.dll' (C RunTime - MultiThreaded). I would hope that the .NET compiler uses this 'msvcrtmt.dll' when 'multithreaded support is on', but I couldn't tell you for sure. If you're statically linking, I think the name is just 'msvcrtmt.lib'. The thread-unsafe version doesn't have 'mt' appended to the library filename. The glamour of MSFT development has been largely replaced with a desire to actually get stuff working so... most of my development has been on FreeBSD lately. Therefore some of this MSFT specific information may not be exactly correct. Oh how the cobwebs accumulate! Anyway, you could probably double check for the 'msvcrtmt' library by looking at the detailed linker settings, that is if my suspicion concerns you and you're still interested in isolating the problem. In any case, I'm glad you found a work-around! C. Michailidis Balston Research LLC _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------
Sliwa, Przemyslaw (London) wrote:
Hi,
Thanks for help,
On a Linux box I have to link against libc_r too? Probably yes, but could you confirm this?
No. Just use the compiler options "-pthread -D_REENTRANT" consistently. libc_r is a BSD thing.
It seems the usage of the vector cases problems with the multithreaded programs on the multiprocessor machines. I have changed it to queue and the bug has been resolved. I cannot reproduce it now.
I think the bug might lie in the copy-assignment operator for CFXTrade. std::vector<CFXTrade> may use that whereas std::queue<CFXTrade> probably will not. By the way, what are you planning on doing with the money left over as a result of rounding errors? (Seriously, double is not a suitable type for representing amounts of money. Check your local accounting regulations.) Ben.
participants (2)
-
Ben Hutchings
-
Sliwa, Przemyslaw (London)