If we strictly subscribe to that philosophy, then we would have only simple
locks, and no recursive locking. The two additional functions I added is
complex (reader/writer) locks and recursive locking.
The Posix argument for simplicity really depends on
1. The cost of layering more complex locks on top of simpler locks.
2. The frequency of usage of the more complex locks.
(1) The cost can be significant in a message-passing, distributed memory
environment, because of the need for additional messages. This is different
from the Posix situation, where the cost of acquiring a lock is likely to
dominate the cost of doing some simple critical section code that implements
the complex lock function.
(2) The argument about frequency of usage is less clear in my mind. I believe
that reader/writer locks will be used frequently in our environment, and that
recursive locking will be unfrequent.
A separate discussion is about the user functions we supply in MPI: if complex
are recursive locks are needed frequently, then we may want to provide them
anyhow, in the MPI library.
The argument for recursive locking is modularity: a function is called, it
needs a lock, and it is not known whether the lock has been acquired by the
caller. Recursive locking allows the callee to acquire and release the lock
in the manner, in both cases. (I am cheating here. To do this cleanly, I need
to do more than in my current writeup: I also need to support the case where
the caller holds a read lock and the callee requires a write lock. Thus, a
read lock can be promoted to a write lock, and when such promoted write lock is
freed, it reverts to a read lock.)
To sum up: I don't see this as a make or break decision. If we stick to
reader/writer, recursive locks, I shall change the spec to say that a read lock
can be promoted to a write lock, and demoted back. If we say that locks are
nonrecursive, I would argue that the outcome of recursive locking should be
undefined, since the overhead of returning the "you-already-have-the-lock"
information will not be much less than the overhead of incrementing the lock
count: disallowing recursive locking is a saving only if we leave the outcome
undefined.
---------- Forwarding Original Note --------
To: mpi-1sided @ mcs.anl.gov @ GW3
cc:
From: salo @ mrjones.engr.sgi.com ("Eric Salo") @ GW3
Date: 07/02/96 11:31:13 AM
Subject: Re: a (radical ?) alternative to current chapter 4
Security:
Is there a compelling reason to make the locks recursive? Seems to me that you
either have a lock or you don't; this smells more like a semaphore. For the
sake of simplicity, I guess my preference would be to make the locks
non-recursive. But if we do want more generality then I think we need to
provide more information in the API. For example, do we just want to return
TRUE if we already own the lock and try to grab it again? Maybe instead we
should have three possible return codes: TRUE, FALSE, and YOU_ALREADY_HAVE_IT.
Or we could just return an int, where zero means that you don't have it, in
which case we would also need a way to set the initial value.
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-808 last Xon said, just salo@sgi.com Mountain View, CA 94043-1389 before he died?"