in reply to Re^7: OT: Locking and syncing mechanisms available on *nix.
in thread OT: Locking and syncing mechanisms available on *nix.

Thanks, but the trouble with that is we now need 3 elements. The flag, the cond_var and the mutex.

And the only 'reason' for using the mutex appears to be to serialise access to the flag. But mutexes always require a user/kernel/user space transition which is horribly expensive, when the same job can be done on modern processors using memory barriers and atomic instructions.

For example, the ready flag state changes can be safely done entirely in user space using gcc's Atomic builtins.

But that still doesn't allow us to ditch the mutex, because the only signalled wait construct is the cond_wait, which requires a bloody mutex.

Many of the issues, and solution to them, are discussed in Mutex .v. futex. What I've yet been unable to find is the documentation (and discussion of availablity) of futexes?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^8: OT: Locking and syncing mechanisms available on *nix.

Replies are listed 'Best First'.
Re^9: OT: Locking and syncing mechanisms available on *nix.
by educated_foo (Vicar) on Mar 27, 2011 at 16:30 UTC
    It looks like there are futexes down there in the hairball that is glibc. AFAICT either they or atomic test-and-set are used to implement pthread mutexes, rather than an OS call (but I just glanced at the code, so don't take my word for it).

    If thread-switching performance is really critical, and pthreads are too slow, would some form of cooperative threading work?

[reply]

      Thanks. I'll take a look at glibc. Any feel for how widely available it is across *nixes?

      If thread-switching performance is really critical, and pthreads are too slow,

      You've got the wrong end of the stick. It isn't the pthreads or threads that are too slow, it is threads::shared.

      Vis. Using Thread::Queue (which uses threads::shared and its cond vars and mutexes), the best throughput I've achieved between two threads is about 50,000 scalars/second.

      My current implementation is achieving (on Windows using event objects) 500,000 scalars/second reliably, and I've seen close to twice that.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        Hopefully we're on the same page now, though I'm getting well outside my area of personal experience (I've done threaded programming, but avoid it like the plague in Perl). IIUC switching between Perl interpreter contexts is painfully expensive, and since each queue message requires 3 switches (wait/signal/wake), that can crush you.

        I haven't used them before, but isn't this a good place to apply Coro and/or Coro::EV? The Coro docs even say:

        Benchmarks using i-threads which are communication-intensive show extremely bad behaviour with i-threads (in fact, so bad that Coro, which cannot take direct advantage of multiple CPUs, is often orders of magnitude faster because it shares data using real threads, refer to my talk for details).
[reply]

In Section Seekers of Perl Wisdom