topic Re: Behaviour of the LOCK macro on a multiprocessor in Operating System - OpenVMS

Behaviour of the LOCK macro on a multiprocessor

Kris Clippeleyr — Fri, 16 Sep 2005 06:04:07 GMT

Hi,
Recently, I installed a working program of mine on a dual CPU DS25 running VMS 7.3-1.
Unfortunately, the program exits with status code %x85CB4100.
Running the same program on a single CPU AlphaServer 1000A running VMS 7.3-1, it works fine.
Intrigued I was I stripped down the program, and it seems that the error occurs in the LOCK macro in the only Macro-32 module in the program.
The procedure is called indirectly by $CMKRNL, tries to acquire the SCHED spinlock, does something nasty, and releases the spinlock before returning to the main stream of execution.
The 3 lines of Macro to acquire the spinlock, I snatched from SYS$EXAMPLES:LAT$RATING_DPT.MAR.
After some testing, I found that if I changed the code to specify PRESERVE=YES, the routine executes as expected on both uniprocessor and multiprocessor systems. If I specify PRESERVE=NO, the routine fails on multiprocessor systems, but still executes flawlessly on uniprocessor.
Someone any ideas why?
Thanx,
Kris (aka Qkcl)

Note: Source code for main program (in C), and kernel mode routine (in Macro) attached.

Re: Behaviour of the LOCK macro on a multiprocessor

Volker Halle — Fri, 16 Sep 2005 07:07:41 GMT

Kris,

this is a question for me ;-)

May I suggest, that you use the .LIST MEB MACRO statement (just insert it before invoking the LOCK macro) and compile your MACRO program with /LIST. This will show the macro expansion in the source listing.

The PRESERVE={YES/NO} clause will cause R0 to be preserved around the LOCK/UNLOCK macro invocation.

On a uniprocessor, the LOCK/UNLOCK macro will just raise/lower IPL and not touch R0 at all - so it will work as expected whether you use PRESERVE=NO or PRESERVE=YES.

On a multiprocessor, the macro will call SMP$ACQUIRE or SMP$RELEASE, which will modify R0. The 'status' value found in R0 (%x85CB4100) is not a status value, but most probably the address of the SCHED spinlock structure left in R0 on return from SMP$RELEASE.

So to make this code work correctly, you need to use PRESERVE=YES, if you want to preserve the contents of R0 around the LOCK or UNLOCK macro invocation.

Volker.

Re: Behaviour of the LOCK macro on a multiprocessor

Volker Halle — Fri, 16 Sep 2005 07:14:50 GMT

Kris,

here is a pointer to documentation of the LOCK macro in VAX Device Support Reference Manual:

http://www.sysworks.com.au/disk$vaxdocjun963/decw$book/dy4yaa28.p123.decw$book#555

Volker.

Re: Behaviour of the LOCK macro on a multiprocessor

Kris Clippeleyr — Fri, 16 Sep 2005 07:48:42 GMT

Volker,
Spot on.
Expanded Macro code shows
MOVL S^#SPL$C_SCHED,R0
JSB G^SMP$RELEASE
MTPR (SP)+,S^#PR$_IPL
RET
So, R0 is definitely touched. So the calling routine does not get a proper return status.
But this then leaves the question how to determine if the SMP$ACQUIRE or SMP$RELEASE routines executed properly.
Btw, thanx for the pointer to the docs.
Kris (aka Qkcl)

Re: Behaviour of the LOCK macro on a multiprocessor

Volker Halle — Fri, 16 Sep 2005 07:59:59 GMT

Kris,

if SMP$ACQUIRE or SMP$RELEASE would fail, you'll probably notice, as you'll get a system crash ;-)

Both routines do not return an output status value in R0. R0 will be modified though.

Volker.

Re: Behaviour of the LOCK macro on a multiprocessor

Kris Clippeleyr — Fri, 16 Sep 2005 08:23:17 GMT

Got what I wanted.
Thanx again Volker.
Kris (aka Qkcl)