Everhart,Glenn
From:	per@mimer.nospam.se
Sent:	Thursday, April 23, 1998 11:51 AM
To:	Info-VAX@Mvb.Saic.Com
Subject:	Re: Interlocked 'instructions' on the Alpha
In article <009C518E48D5F58B.80E0@omc.bt.co.uk>, LOCKS@omc.bt.co.uk (Steve Lock, SVH x4944) wrote:
>Hi folks,
>
>Are the emulated VAX instructions INSQTI, REMQTI et al still interlocked on
>the Alpha?

Yes, they are emulated by PAL code and the operations are indivisible.

If you are using C, see:
$ HELP CC lang built __PAL_INSQ

>
>Specifically, I have a piece of code in an RTL which has been designed to
>be thred-safe.  It has a mutex protection around accesses to its internal
>queues which are manipulated with lib$insqti/remqhi.
>
>Now, it turns out this code not only gets called from multiple threads but
>also from both AST and non-AST level.  This leads to the inevitable
>deadlock on the rare occasion when the AST comes through the routine and
>waits on the mutex when it's already been taken at non-AST level.

You should avoid mutexes in AST routines. Use atomic queues or non-locking 
synchronization.

>
>I've considered a number of solutions, including (amongst several others!)
>performing a non-blocking check on the mutex and then getting out without
>doing anything (ie- lose the queue entry) if the mutex is set *and* we're
>currently at AST level, but it occurs to me that a nicer solution is to get
>rid of the mutexes all together, if its safe to do so.
>
>I have R'd TFM for the routines in question, and it doesn't contain any
>warnings about atomicity on the Alpha, but thought I'd poll the group
>anyway.
>
>BTW, I am aware that it's documented as 'not safe' to call thread routines
>from AST level, and have been bitten by some routines, but I'm "told" that
>the mutex functions are, in fact, safe.  This doesn't relate to my problem,
>I mention it just to head of a potential discussion about how unsafe it is
>to call into the threads RTL at AST level in any case.

I believe that the only pthread routine that is safe to call from AST level 
is pthread_cond_signal_int_np().

You should also avoid calling any other routines from AST level that might 
implement "thread-safety" by doing some pthread_mutex_lock() (or similar) 
calls internally.

I have an example of a "queue package" at 
ftp://ftp.mimer.se/pub/repro/smprq.c
This code implements a queue of integer values. You can put elements on the 
queue from AST and non-AST code. Only non-AST code can dequeue elements.

In the non-AST case, you need to lock/unlock a mutex even though you are 
dealing with atomic queues! I think my implementation looks a bit silly 
because of this, but it is the best I can do. Constructive suggestions are 
welcome!

Regards,
  Per


l

--
/Per