[boost] Thread safety

From: John Maddock (John_Maddock_at_[hidden])
Date: 1999-12-30 06:42:58

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
like:

class myobject
{
public:
   /* methods */
   void my_method();
private:
   lock_type l;
};

void myobject::mymethod()
{
   guard_type g(l);
   // do something thread safe....
   g.acquire(false);
   // do something not thread safe
   g.acquire(true);
   // 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.