At 14:09 -0600 on 08/01/2006, Paul Gilmartin wrote about Re: Data set
ENQueues and DEQueues in Jobs:
But, yes, I was using rhetoric to make the same point Binyamin made
more explicitly: doing a DEQ; ENQ is subject to the same hazard
of interruption by other jobs whether one uses the sequence to
downgrade or upgrade an ENQ. If it's unacceptable for upgrading,
it's likewise unacceptable for downgrading.
HOW is it unacceptable for downgrading?
How does USER1 holding an EXCLUSIVE ENQ (while USERS 2-10 are waiting
on the ENQ=SHR wait queue [followed by USER 11 waiting on the queue
with an ENQ=EXC request]) and DEQ'ing (thus releasing USERS 2-10)
differ from USER 1 doing an E->S downgrade (thus retaining a SHARED
ENQ and releasing USERS 2-10)? The same result occurs (ie: USERS 2-10
get released and get the shared ENQ). USER 1 in the latter case acts
as if it were on the SHR wait queue somewhere ahead of USER 11. IOW:
USER 1 does not deadly embrace, run the risk of having to wait to
resume execution, or getting canceled.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
