develooper Front page | perl.perl5.porters | Postings from August 2001

Re: SV: Implementing Callbacks (Was: RE: [PATCH] Adding callbacksto thecore)

Thread Previous | Thread Next
From:
Arthur Bergman
Date:
August 23, 2001 01:01
Subject:
Re: SV: Implementing Callbacks (Was: RE: [PATCH] Adding callbacksto thecore)
Message ID:
B7AA84CB.345B%arthur@contiller.se
01-08-22 22.46, skrev David M. Lloyd på dmlloyd@tds.net följande:

> We *do* need the mutex, because otherwise the value of PL_callback_head
> could change in the time between the comparison and the assignment.
> After all, a thread can enable a callback at any time.  In any case, the
> cost of the mutex AND the assignment is negligable because it is only used
> *one opcode after* a signal has been handled.  Which is infrequent.  It's
> the operation that occurs with every opcode (that is, three comparisons,
> and the for loop, but NO mutexes) that I'm more worried about. In fact, if
> your Perl script never gets a signal, and has one callback that is enabled
> then later disabled, the mutex is only exercised two times in the entire
> life of the program.  Add a signal, and it's three times.  Not a huge
> impact, right?

if(async) {
    if( signal) { do signals}
    mutex_lock();
    if ( callback) { do callbacks}
    mutex_unlock();
}

What am I missing?

I suggest that another thread is never allowed to modify if a callback is
enabled or not. So we can do

if(async) {
    if signal do signals
    if callback do callbacks
}

If a callback needs to get data from another thread or disable on cue from
another thread, it should take care of it's synchronization by itself. So
any modifications to the callback structure must happen in the main thread.

Infact, to be realy sure about this (remeber the memory visibility rules.
You would need to do.


mutex_lock();
if(async)
...
mutex_unlock();

And that is clearly not acceptable.

-- 
Arthur


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About