This is the mail archive of the frysk@sourceware.org mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

EventLoop.isCurrentThread() race condition


I was wondering whether anyone is actually depending on the side effect
of the isCurrentThread() method in frysk.event.EventLoop, in that it
assigns the tid of the current thread as the identifier for the event
loop thread if it wasn't assigned before.

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

The fix is of course to remove the side effect from isCurrentThread(),
but I'd rather not commit that until I know that there isn't someone
who actually depends on this behaviour since it has been in existance
since Apr 18, 2007.

For reference, I ran all tests with the current side effect in place,
and then re-ran all tests again with the patch applied.  The results
were identical (modulo tests that intermittently fail due to the
updateTid() esception).

	Cheers,
	Kris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]