Re: [nbpp-devel] Possible race condition in MultiThreader() daemon

[Benjamin G. <ben...@bt...>]

On Fri, May 18, 2001 at 02:52:14PM +0100, Daniel Barron wrote:
> In my DansGuardian I have a class object in the main class that has the
> main() function.  This object reads a bunch of conf files early in the
> main(), well before the return daemon.run();.  The object contains code and
> data.  The object is used in the other classes and the handleConnection().
> 
> Have I done a bad thing?  As the object is AFAI can tell shared between the
> threads, this would cause a race condition and could cause random crashes?
> It contains non-mutex-protected code remember.  Am I right?

You're right that the object is accessed by multiple threads.  This would
only be a problem if the object is modified after daemon.run() is called.
It's OK to create an object, then create a bunch of threads, and let them
all read from the object.  But if anything modifies the object, you could
have problems.

> Perhaps I could take a copy of the object in the handleConnection() and use
> that instead to solve the problem?  What do you think?

Well, you could still have a race condition, because one thread could be
modifying the object while another thread is copying it.

I'd suggest using an RWLocker.  If each of the object's methods leaves the
object in a consistent state (so that it would be OK for one thread to
call any of the object's methods, and then for another thread to call any
of the object's methods), then the easiest thing to do would be to put the
RWLocker in a member variable in the object (as in the nb++ examples), and
acquire it using ReadLock and WriteLock objects as necessary in the
object's methods.

-- 
Benjamin Geer
http://www.btinternet.com/~benjamin.geer