RE: [boost] RFC: Multithreading design constraints

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 
> portability
> between pthreads and Win32, as well as covering other threading models
> (Solaris) that don't quite fall into the POSIX camp.

<RANT>
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.
</RANT>

<THOUGHT>
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
difference.

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
their inclusion.

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
usage).

</THOUGHT>