[Tcl-bugs] [ tcl-Bugs-3611974 ] InitSubsystems multiple thread issue

[SourceForge.net <no...@so...>]

Bugs item #3611974, was opened at 2013-04-26 11:55
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3611974&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 02. Event Loops
Group: current: 8.5.14
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Porter (dgp)
Assigned to: Jan Nijtmans (nijtmans)
Summary: InitSubsystems multiple thread issue

Initial Comment:

The mutex arrangement in TclInitSubsystems() seems
to suffer from a significant flaw.  Consider two threads,
A and B, calling the routine concurrently.  Thread A gets
the lock first, sets subsystemsInitialized to 1 and starts
calling the set of subsystem initializing routines.

Meanwhile thread B makes the initial test 
(subsystemsInitialized == 0) and since thread A
has already set it to 1, thread B jumps straight
to the bottom of TIS() and calls TclInitNotifier().

The trouble is when B calls TclInitNotifier(), we
have no idea how much of Tcl library initialization
is actually done.  We just know it got started.


----------------------------------------------------------------------

>Comment By: Don Porter (dgp)
Date: 2013-04-29 06:24

Message:
Of course, once we make Tcl_InitSubsystems() a public
routine that any extension might call at any time (buggy
as that might be), the problem will come right back.

The 4 state makes no functional difference that I can see,
but I agree it feels a bit more polished that way.  I'll
commit that change to the branch.

Thanks for looking it over.  

Working through this got me started
thinking about ways to do this better, but
as you say, that's a novem project.  Will
keep that in other branches and tickets.

----------------------------------------------------------------------

Comment By: Jan Nijtmans (nijtmans)
Date: 2013-04-28 14:11

Message:
Two remarks:
- Tcl_Finalize could be handled as well by using 4 states in stead of 3:
     CHANGING -> STARTING | FINISHING
- If Tcl_CreateInterp wouldn't call TclInitSubsystems(), but in stead
  the application was required to call TclInitSubsystems() first, this
  problem wouldn't exist at all. But that's food for Tcl 9.

Further on, I agree with this change. It doesn't really solve
the problem, but a panic is better than leaving the system
in an undefined state. I'll have a further look.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2013-04-26 12:02

Message:
Branch bug-3611974 committed:

Revisions to the multi-thread arrangments of TclInitSubsystems().
With these changes, the caller of TclInitSubsystems() can be sure that
at some point after the TIS() call is begun and before it returned, the
Tcl
library became fully initialized.  Without these revisions, that cannot be
guaranteed, TIS() can return with Tcl library initialization having never
been finished.

Even with these revisions, the caller cannot be sure the library remains
initialized.  Any thread might call Tcl_Finalize() at any time.  That's a
deeper problem which this patch does not attempt to address.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3611974&group_id=10894