>>> The main difference is, that in the 'radical new draft' during
>>> the PUT the whole window is locked!!!
>> If the cocnurrent PUTs do not update the same location in the
>> window then one can use a shared lock for the puts, rather than
>> an exclusive lock. So, all puts can go one concurrently.
> This is a bit confusing. The current text of the alternate proposal uses
> and "write" to describe the two different types of lock, since this is what
> they will typically be used for. It may or may not be more correct/clear to
> label them as "shared" and "exclusive" locks instead, but that's just a naming
Marc, it looks a little bit strange, because it must be a lock, that
can be aquired by multiple processes for write but only by one process
for read. Normally one has the contrary case -- multiple read but
only single access for write.
If the users are allowed to use the read/write locks in the contrary
manner then it must be explicitly stated. In the moment page 3 lines
6+7 are saying:
"...each read access to a window is protected by a read lock, and
each write access to a window is protected by a write lock on that
Since the full text was already put out by Steve, I suggest that you look
there. It says (pg 293, l34):
"Each access to a window is protected by a lock on that window; conflicting
accesses use mutually exclusive locks. (Typically, read accesses are protected
by shared locks and write accesses are protected by exclusive locks; but this
is not required.)"
I.e., if one process puts at a location, and another process gets from that
same location, then both use locks, and at least one of the two locks is
exclusive. They can also synchronize with barriers, rather than locks. But,
if the processes access different locations, their accesses need not be
synchronized one with respect to the other, at all.
The way to thing about this proposal is as follows:
We define what are conflicting accesses: accesses conflict if they go to the
same location and at least one one is an update. And, (that's where we are
somewhat unnatural) accesses conflict if they go to the same window, one is
local and the other is RMA, and at least one is an update. Whenever there is a
pair of conflicting accesses, then there must be a synchronization that
involves both processes, that orders these accesses. This synchronization is
where we execute coherence actions.
We can now debate variants:
Is the coherence action explicit (old proposal) or implicit (my new proposal
and, I believe, diNucci's proposal).
If it is implicit, then what sychronizations drive which coherence actions, and
on what objects.