in reply to Semaphores failing to prevent race condition

— Are Curses.pm and Thread::Semaphore known for certain to be thread-safe on multi-core processors?

My understanding is, there is only thread-safe or not thread-safe, and since Curses doesn't go so far as to mention thread safety, its safe to assume it isn't thread-safe.

Thread safety isn't that important, if you stick to the rule of thumb to only require the unsafe modules you need in child threads.

The other rule of thumb is to only have one thread doing GUI stuff, and have all the other threads signal it.

  • Comment on Re: Semaphores failing to prevent race condition

Replies are listed 'Best First'.
Re^2: Semaphores failing to prevent race condition
by ikegami (Patriarch) on Mar 13, 2011 at 06:07 UTC

    Thread safety isn't that important, if you stick to the rule of thumb to only require the unsafe modules you need in child threads.

    You're confusing threads and processes here. Perl code is shared across all of the process's threads. It doesn't matter when you require the module.

    My understanding is, there is only thread-safe or not thread-safe

    I usually classify as:

    • Safe to use from multiple threads.
    • Safe to use from just one of the threads.
    • Not safe to use when threads are used.
      You're confusing threads and processes here.

      No I am not. If you use Tk; or some other module, and then you use threads, instead of using require Tk;, you'll run into segfaults, etc etc. Using require Tk; avoids the issue completely.

        Then your rule of thumb is wrong. "Only require the unsafe modules you need in child threads" doesn't make sense. Requiring a module in one thread loads it for the entire process. Perhaps you misstated what you meant?

        Or not:

        $ cat Mod.pm package Mod; print __PACKAGE__, "\n"; 1; $ perl -Mthreads -e'my @t = map { async { require Mod; }; } 1..2; $_-> +join() for @t;' Mod Mod