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

[Daniel B. <nb...@ja...>]

In message <200...@lo...> you wrote:

> 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()
[snip]
> 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.

The object does not get modified.  It contains lots of variables and
deques as well as code to check if a passed string is in one of the deques.
The only 'modification' is some for(int i;;)s which I presume would
create local variables on the stack?

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

No, it does not get modified.

[snip]


I thought the possible race condition (which it seems was not there after
all) might have caused my random crashes, but not :(

-- 
Daniel Barron
(Visit http://dansguardian.org/ - True web content filtering)