From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-06-06 08:31:45
> -----Original Message-----
> From: John Maddock [mailto:John_Maddock_at_[hidden]]
> Sent: Tuesday, June 06, 2000 8:03 AM
> To: INTERNET:boost_at_[hidden]
> Subject: Re: [boost] RFC: Multithreading design constraints
> BTW as well
> as the GNU win-pthreads, ACE also demonstrates the degree of
> between pthreads and Win32, as well as covering other threading models
> (Solaris) that don't quite fall into the POSIX camp.
You should be careful before putting too much faith in ACE's portability. I
tried to use it a few years back because I wanted an IPC mechanism that
would work on SunOS and Win32 ( but need not interoperate). I think I tried
to use FIFOs. It took me a while to muddle through the sparse docs, and I
finally got everything to compile ok. When I tried to use the functionality.
I got some sort of 'unsupported' runtime error code on Win32. No compile
errors. No portability documentation (at that time). Pretty lame for a
software library that purports to "perform common communication software
tasks across a range of OS platforms". FIFOs, although not supported by
primitives, could fairly easily be emulated on Win32.
In the end I think I ended up using TCP sockets, since they are well
supported on old SunOS (no pipes if I remember right) and Win32.
YMMV, and ACE might have come a long way since my experience. Personally, I
will think twice before I ever try ACE again.
As far as completeness of interface vs. simplicity of atomic operations. I
was a bit surprised by John Maddock's observation of the atomic vs. critical
section code. I would've expected more than a 3-fold performance
I like the ability of being able to use primitives (when available ) for
inc/decrementing and read/write. As far as the more esoteric operations
(tas/tar/cxc), I am ambivalent. I can see advantages and disadvantages for
I agree with Miki's opinion, "is_specialised and has_* should be removed.
Even in absence of native atomic operations, all of these can be implemented
in terms of mutex." I think the is_* and has_* members could distract and
confuse the class users and might be an added discovery cost (barrier to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk