Boost logo

Boost :

From: Curtis Clauson (LlelanD_at_[hidden])
Date: 1999-12-30 16:28:59

Has anyone considered the ACE (Adaptive Communications Environment) open
source package? This is a multi-platform C++ package created by Professor
Douglas C. Schmidt and team between Washington University in St. Louis MS
and UC Irvine in Irvine CA. It includes a rather complete set of classes and
wrappers for inter-process communications and thread safety and management
which could be of use here as an included base to thread safe versions or
wrappers for your libraries.

Related links:
Professor Douglas C. Schmidt -

The ACE docs have the following paragraph on tested platforms:

ACE has been ported and tested on a wide range of OS platforms including
Win32 (i.e., WinNT 3.5.x, 4.x, Win95, and WinCE using MSVC++, Borland C++
Builder, and IBM's Visual Age on Intel and Alpha platforms), most versions
of UNIX (e.g., Solaris 1.x and 2.x on SPARC and Intel, SGI IRIX 5.x and 6.x,
DG/UX, HP-UX 9.x, 10.x, and 11.x, DEC/Compaq UNIX 3.x and 4.x, AIX 3.x and
4.x, DG/UX, UnixWare, SCO, and freely available UNIX implementations, such
as Debian Linux 2.x, RedHat Linux 5.2 and 6.0, FreeBSD, and NetBSD),
real-time operating systems (e.g., LynxOS, VxWorks, Chorus ClassiX, QnX
Neutrino, and PSoS), MVS OpenEdition, and CRAY UNICOS. A single source tree
is used for all these platforms. There is also a Java version of ACE.

(Note: This is my first posting to this forum and I'm not sure yet if the
eGroup servers will correctly deal with the Outlook sourced mail format in
creating the text summaries like other forums do. Let me know if you get
HTML or RTF garbled text and I'll fix it.)

        The Snake Pit - Development
Curtis Clauson LlelanD_at_[hidden]

-----Original Message-----
From: John Maddock [mailto:John_Maddock_at_[hidden]]
Sent: Thursday, December 30, 1999 3:43 AM
To: INTERNET:boost_at_[hidden]
Subject: [boost] Thread safety

I didn't want to get involved in this until type traits was out the door,
but I've also needed some (very basic) thread synchronisation primitives to
allow for lazy-evaluation of pattern-matching internal state types.

I defined three types:

counted_t - (optionally) thread safe reference counter type, may be either
a class or a built in type depending upon the implementation - needs to
declared volatile in use.

lock_type - thread synchronisation primitive - has no public methods other
than construct/destruct.
guard_type - exception safe way to acquire a lock, usage looks something

class myobject
   /* methods */
   void my_method();
   lock_type l;

void myobject::mymethod()
   guard_type g(l);
   // do something thread safe....
   // do something not thread safe
   // do something thread safe...
   // lock released when g goes out of scope or upon stack unwind.

>It's not optimization within the library call that hurts,
it's optimization around the library call, so it you would
have to put volatile in your own code to protect it from
thread switches. I think it's sort of like the restrictions
on setjmp, but I hurd this talk years ago and don't recall
the deatials.<

According to 1.9 para 16 there is a sequence point about each full
expression - so I don't think volatile is required in the kind of usage
outlined above?

- John.

ps - this isn't really a proposal - its just some code that I've found
useful - I guess what I'm trying to say here is that some code to make
boost thread safe is important - and that it doesn't necessarily require a
full multi-threading library, at least in first instance. On the other
hand if someone wants to take on the task of writing one that's another
matter - come to that if necessary primitives can be added one at a time.

The only fruitcake at is our manager.

He's giving away a $20 coupon, plus our everyday Free Shipping.

Take advantage of the savings and selection now.

-- Create a poll/survey for your group!

Boost list run by bdawes at, gregod at, cpdaniel at, john at