0

Since Tcl uses Apartment Threading Model as its fundamental multithreading frame, every tcl interpreter obj is bound to the thread that creates it. In my program, each thread invokes Tcl_CreateInterp to create its own interpreter the first time it needs to invoke any tcl commands. But the Q&A test reported that valgrind (v3.13.0) complains possible data race issue when threads intend to create their own interpreter. The data race happens at apis Tcl_NewStringObj/TEBCresume/TclNREvalObjv, etc. Anything to correct for my use model? Or is it false positive of valgrind?

I use boost::thread_specific_ptr to manage the thread local interpreter.

Tcl_Interp* GetThreadInterp()
{
   static boost::thread_specific_ptr < Tcl_Interp >  tcl_interp;
   if (!tcl_interp.get())
       tcl_interp.reset(Tcl_CreateInterp());
   return tcl_interp.get();
}
Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
Novak
  • 3
  • 3
  • I'm not in a position to run valgrind right now (I'm on a tablet). Got any more information, perhaps from a symbols-enabled debug build? We know of issues on shutdown with stuff not being freed due to accelerated finalization, and the accelerated thread-specific memory allocation system confuses things too, but neither should be reported as a startup data race to my knowledge. – Donal Fellows Jan 14 '20 at 05:59
  • Also, are you calling `Tcl_FindExecutable(nullptr)` once ahead of time (to initialize the library itself)? You can call that from main or somewhere early like that. – Donal Fellows Jan 14 '20 at 14:55
  • @DonalFellows Yes, it is symbols-enabled debug build. What is calling Tcl_FindExecutable(nullptr) for? Something uninitialized causes data race? – Novak Jan 15 '20 at 02:48
  • It is a one-off library initialization. You can use `argv[0]` instead of `nullptr`, but that's not so useful when embedding (unless your scripts really need `info nameofexecutable`). That API function has a not-very-obvious name, we know, and probably should be called something like "initialize Tcl library". If the fault is due to missing that (and needing to do the needful later) then we'll write this off as minor API misuse. – Donal Fellows Jan 15 '20 at 06:31

0 Answers0