How wide is SYS$SETRWM

[Roger Strandberg SEB]

Hi

My question reside on how wide is the SYS$SETRWM, does it effect the SYS$ENQW?
Can it effect other programs started from same GROUP/SCHEDULER etc..........

[Hoff]

AFAIK, everything.

This is a arguably nuclear application self-destruct lever outside of an application where you control everything -- and those basically don't exist any more. You're almost inevitably calling into an RTL somewhere.

If you'd like to risk weird and potentially unhandled errors within most anything you might call most anywhere in the call chain (directly or indirectly, too), have at.

Now if you'd like to discuss the real problem here -- that there's a nasty little trade-off where you inevitably have to decide to hang or to drop a packet when operating in traffic spikes or otherwise past the application throughput limits -- that's another matter.

I'd tend to look to design such an application to have enough quotas to avoid running into the quota blade guard; the process quotas are the means by which an application error is (usually) prevented from triggering or escalating into a system-wide failure.

Yep, probably not the answer you wanted. :-)

Stephen Hoffman
HoffmanLabs LLC

[John Gillings]

Roger,

Whatever you think SYS$SETRWM will do for you, it won't!

You should only turn off RWM if you know the entire instruction stream up to the point it's turned back on. When it's used correctly it would be for a short duration critical region. I'd go so far as to say there are NO valid applications where RWM is disabled permanently at the process level.

Yes, it affects all system services, including SYS$ENQ(W). If the $ENQ request requires allocation of a resource which cannot be satisfied immediately, RWM determines behaviour.

Example - an $ENQ for a new resource will need to allocate a RSB and LKB from non-paged pool. With RWM enabled, $ENQ will wait if the resource isn't available, with it disabled $ENQ will return immediately with some kind of failure status.

If there are no resource issues, $ENQ(W) will behave in exactly the same manner with RWM on or off. RWM disabled will NOT prevent $ENQW from waiting for a lock if the request is incompatible with an existing lock.

$SETRWM is intended to be used in time critical code, where you need to avoid any wait states. I wouldn't expect to see a $ENQW in such a code path!

Zen answer... if you have to ask questions about using $SETRWM, you shouldn't be using it! ;-)

[Roger Strandberg SEB]

Hi. Thx for answers....


I tested the SETRWM in a basic program.
First i do SETRWN(1) disable and on resturn checks the SS$_WASSET just to make sure.

Then i do a ENQW for a resouce i've just lock via another window.
The ENQW still waits untill i do a another look to same resource. And then i get a normal deadlock.

[Ian Miller.]

So you are looking to lock a resource using $ENQ but do not wish to wait if the resource is not available?

Perhaps you need the LCK$M_NOQUEUE flag.

[Roger Strandberg SEB]

Well no....

I do:
"Some handling with enqw"
SETPWM()
QIO
SETPWM()
"Some handling with enqw"

The enqw are used to lock a shared area.
And some how this area get wrong data in it.
I suspect that the lock is not right.
I do handle deadlocks.

I have several programs that handle this share area in the same way.
=>
Thats why i asked how wide the setpwm, if it's just local to the program....

[Ian Miller.]

It is local the process.

What are you trying to achieve by turning off RWM around a QIO?

[Hoff]

So you're not using any calls into language RTLs nor any external libraries nor any (other) system services? Cool. It'll do just want you want. Have at...

If, on the other hand, you're using language RTLs or (other) system services or such, well, those typically are not coded to expect nor to contend with having resource wait disabled.

In most every case I've seen over the years where this has been proposed, the application is non-trivial and the call can be potentially hazardous; it's better to code the application with either an AST or a timeout or a NOW flag or other such feature. To code the application to explicitly react appropriately under load; to stall, to back-pressure or to drop messages.

FWIW, the potential RWM weirdnesses can be subtle and very hard to replicate, too.

[Hoff]

[[[The enqw are used to lock a shared area.
And some how this area get wrong data in it.
I suspect that the lock is not right.
I do handle deadlocks.]]]

Some application code is broken, yes.

Are any SMP systems involved here?

Some code is not contending correctly with the shared memory around the processor caching (a particular factor when Alpha and shared memory and SMP are ill-mixed together), is going around or otherwise ignoring the locking, or other such arcana.

There are a wide variety of ways to go off the rails here.

Use of RWM will almost certainly make things worse, too.

In recent years, I've tended to avoid using or migrate away from home-grown shared memory code -- even my own code -- and move to RMS files with global buffers. Shared memory looks good right up until you start dealing with these sorts of cases.

[Roger Strandberg SEB]

Well it's hard to predict....

We use it when writing to mailbox.
by placing the SETRWM the old programmer (not me) wanted to catch if the mailbox was full and then write it to an overflow.
Like:
If SYS_STATUS = SS$_MBFULL then
!Overflow
else
! else everything good..... but is it?
end if

We use it in VERY close to the mailbox all.
At the maximum place we have a simple print function in between.......