Re: EventLoop.isCurrentThread() race condition

[Kris Van Hees <kris dot van dot hees at oracle dot com>]

On Fri, Jun 22, 2007 at 01:14:06PM -0400, Andrew Cagney wrote:
> Kris Van Hees wrote:
> >Some tests in frysk-core
> >are actually using runPending or runPolling in a multi-threaded context
> Can you be more specific here, a thread and perhaps with a sequence
> diagram?  .runPending and .runPolling should be robust in a
> multi-threaded context provided they are being called from the main thread.
>
> My guess is that the above is holding, but then a secondary thread is
> calling into the eventLoop before the primary thread has had a chance to
> pin down that it is the eventLoop thread.  But without knowing what
> specific problem you're refering to it remains a guess :-(

To quote from my original email:
>>Reason for asking is described in bugzilla #4688.  Essentially, we end
>>up with a race condition on what thread ends up setting the tid variable
>>in the EventLoop class.  There are cases where the EventLoop is
>>instantiated (tid is -1 at that point), and then other threads are
>>started that may trigger operations in the core that (usually
>>indirectly) call isCurrentThread() to determine whether work can be done
>>in-line or needs to be placed on the queue.  If that call to
>>isCurrentThread() is reached before the actual event loop thread
>>executes either runPolling() or runPending(), the event loop will
>>register the wrong tid, causing an exception later on (in updateTid())
>>when runPolling() or runPending() is called (from the correct thread).

I believe that explains what you mention above rather well.

> Or as you put it, pending events before the event-loop is started is indeed
> prohibited.  Is this too onerous?  I don't think so:

I assumed that would be the case, which means that the comment block
preceding the run() method in EventLoop is incorrect and definitely
should be updated.

I quote:
    /**
     * Run the event-loop.
     *
     * The event loop is stopped by calling requestStop, and is
     * stopped after all pending events have been processed.  Any
     * existing pending events are always processed before performing
     * the first poll.
     */

Obviously, there should not be existing pending events, and processing
them would in fact lead to an exception.

Can you explain what you are failing to understand in my description of
the problem?

	Cheers,
	Kris