The General Idea

The Need

Using the naive ErrorLog mechanism, two threads issuing error messages at overlapping times will each send instructions to the same ELadministrator. This leads to the possibility of garbled messages. Instead, what is wanted is some way for each thread to independently compose a message, and each message to emerge as one uninterrupted chunk on the destinations.

Meeting this Need

The strategy employed is that the ThreadSafeErrorLog has its own area for building up a message, rather than using the common one in ELadministrator. When the message is completed, the ThreadSafeErrorLog will obtain a lock on the right to be sending a message to the administrator, send the message, and release the lock.

An example of how this can be used is supplied in MultThread.h and MultThread.cc. Here, care is taken to set things up so that each thread has its own ThreadSafeErrorLog, known as errlog. Error messages are then issued in exactly the same way as they would have been through the normal errlog, and the behavior is also the same except that there will be no garbling of the output.

The Mutex (Locking) Mechanism

Now the Exceptions package has no business dictating the actual locking mechanism to the user. Instead, ThreadSafeErrorLog is templated off an arbitrary user-defined class which we name Mutex.

The Mutex class must have two properties:

• It must have a constructor taking no arguments, which locks some lock, semaphore, or resource in whatever manner the user desires.
• It must have a destructor which releases that lock.

pthread_mutex_t* mutex;		// a posix mutex, represented as a global
				// scope pointer, initialized and set up
				// at some early point in the job.
struct Mutex {                                          
  Mutex() { pthread_mutex_lock(mutex);   }
 ~Mutex() { pthread_mutex_unlock(mutex); }
}

Setting Up a ThreadSafeErrorLog for Each Thread

1. errlog might be a global variable of type ErrorLog
2. errlog might be a data member of some Module class, and the various physics routines might be methods in that class (or a subclass of Module) -- those methods can use errlog as if it were a global

The latter method, having errlog as a public or protected ThreadSafeErrorLog data member in a Module class, works fine. Each thread, upon startup, instantiates whatever Modules it requires, and now each Module in each thread has its own ThreadSafeErrorLog which can accumulate its own message independant of activities of other threads.

For example, code in the MultThread example does something like:

class Module  {
public:
  Module( const std::string & name );
  virtual void operator()( Event & e ) = 0; // do this module's processing!
  virtual ~Module();
protected:
  ThreadSafeErrorLog errlog;                     
};  // Module

class DoPhysics : public Module {
public:
  DoPhysics( const std::string & name, int tnum ) : Module(name){}
  void operator()( Event & event ) {
  // ...
  errlog( ELsuccess, "An Event" ) << "data = " << event.data << endmsg;
  // ...
  }
};  // DoPhysics

  DoPhysics  doPhysics( name );

  for ( n = 1;  n < 20;  ++n )  {
    Event event( n );
    doPhysics( event );
  }