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

I'm not trying to mutually exclude anything.
You actually need to mutually exclude access to the condition variable. I don't use Perl threads much, but it looks like threads::shared has the necessary ingredients, and you can do something like this: 
my $cond : shared;
$thread1 = async {
    { lock($cond); cond_wait($cond) until $cond }
    # do stuff.
};

$thread2 = async {
    # do stuff.
    { lock($cond); $cond = "proceed"; cond_signal($cond) }
};

[download]

Replies are listed 'Best First'.
Re^6: OT: Locking and syncing mechanisms available on *nix.
by BrowserUk (Patriarch) on Mar 27, 2011 at 15:10 UTC

    Sorry, I guess I should have mentioned I'm operating in XS with no access to threads::shared. Indeed, I'm specifically trying to replace it.

    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]
      The idea's basically the same, though it's of course uglier using libpthread in C. You have to have both a flag to keep track of readiness, and a condition variable to queue up waiting threads. Here's a rough sketch: 
      #include <pthread.h>
pthread_mutex_t lock;
pthread_cond_t cond;
int ready;

void
consumer() {
    pthread_mutex_lock(&lock);
    while (!ready)
        pthread_cond_wait(&cond, &lock);
    /* lock is locked, ready is true */
    ready = 0;
    pthread_mutex_unlock(&lock);
}

void
producer() {
    /* lock is unlocked */
    pthread_mutex_lock(&lock);
    ready = 1;
    pthread_cond_signal(&cond, &lock);
    /* lock is still locked */
    pthread_mutex_unlock(&lock);
}

      [download]
      libpthread is POSIX, so it should be available anywhere.
[reply]
[d/l]

        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.
[reply]
      hum, XS has access to the entire Perl interpreter. That can't be true.
[reply]
        XS has access to the entire Perl interpreter. That can't be true.

        Yes. But what is the point in coding in XS if you have effectively callback into Perl (even if you only simulate doing so by mocking up the perl calling conventions), for a fundamental part of the process?

        And, what would be the point in using the very thing you are trying to replace, to implement it's replacement?

        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]

In Section Seekers of Perl Wisdom