Re^4: OT: Locking and syncing mechanisms available on *nix.

[BrowserUk]

Ah. Okay. I don't use, nor have any time for the O'Woe dodo that is .NET, so that's of no use to me.

What I'm really looking for (I think) is a *nix equivalent to Windows Event Objects. Basically, a non-polling, non-spinning mechanism to have one thread block until another thread signals.

In theory, pthread condition variables ought to be usable for this. In practice, using a condition variable also requires the use of a mutex, which I don't need or want. I'm not trying to mutually exclude anything. Nor do I see a convenient place to put a mutex that I don't need.

I've run across a few mentions of something called a "futex" which is compared to Window's Event objects, but looking that term up it is defined as a 'fast user mutex'. Again, I'm not trying to mutually exclude anything!

The situation I'm trying to deal with would seem to be a relatively common occurrence. This thread has detected a situation that means it cannot proceed until some other thread does something. It therefore need to block until that other thread signals that it has been done. So, it reset an event and waits for it to be signalled. The other thread signals that event each time it does whatever it is required to do to allow the first thread to move forward.

But I don't see how to do this with *nix?

[happy.barney]

pthread.h: barriers
semaphore.h: semaphores
ipc.h + sem.h: ipc v semaphores
ipc.h + msg.h: ipc v message queues

[educated_foo]

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) }
};

[BrowserUk]

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.

[educated_foo]

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);
}

libpthread is POSIX, so it should be available anywhere.

[ikegami]

hum, XS has access to the entire Perl interpreter. That can't be true.

[nikosv]

wait! this reminded me of some old printouts I had (you never know when they will come handy) so I have the definitive answer for you.

Linux and Windows sync primitives compared side-by-side.(IBM) Port Windows IPC apps to Linux, Part 2: Semaphores and events

[nikosv]

Events can be achieved with a combination of conditional variables and a mutex. Check pthread_cond_timedwait()(search for it inside the page)

[BrowserUk]

I know, but as I don't have anything I want to mutually exclude access to, I don't want to use the (by all accounts very expensive) mutex mechanism.

[sundialsvc4]

Ah. Okay. I don't use, nor have any time for the O’Woe dodo that is .NET.   So that’s no use to me.

I like that!!   My sentiments exactly!   :-D