Re: What's an "MPSAFE" driver need to do?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> On CPU 1:
>>      ask memory subsystem to load datum_1 into i
>>      ask memory subsystem to load datum_2 into j
>>      memory subsystem reads datum_2
>> On CPU 2:
>>      write to datum_1 and datum_2
>> On CPU 1:
>>      memory subsystem reads datum_1
>>      barrier causes: wait for memory subsystem to write i
>>      wait for memory subsystem to write j

> Sure, this would be screwed up, though whatever the barrier does
> should be done between "ask memory..." and "ask memory..." instead of
> where you have it.

That's why the current wording is brokoen: all it promises is that
"complete i=datum_1 before completing j=datum_2".  It says nothing
about how intermediate stages are ordered with respect to one another
or anything else.

> The problem is that the wording you want would seem to prohibit:

Yes, memory barriers are like that.  They typically do prohibit more
than they really need to.  You typically just need order enforced in a
certain way for a few operations.  But, since we don't have any
workable way to name those operations and thus refer to them, we make
do with the sledgehammer of "everything before this" and "everything
after this".

> I think the issue of when something might actually "start" or
> "complete" isn't very strongly related to the thing the barrier
> ensures, which is why I'm not sure the wording matters very much.

Well, the wording has to promise enough that code can count on
something useful; otherwise, there's no point in having memory
barriers.  The current wordings don't meet that test.  (Actually,
strictly, they don't need to, provided something else exists which can
be used to get the necessary guarantees.  But then it's the "something
else" that's useful, not the thing under discussion.)

>> Yes.  That's what I believe it's intended to do, and that's what I
>> think the current wordings don't promise.
> Maybe.  I think your wording suggests the CPU will do something that
> isn't necessary for it to do to guarantee that result.

Yes, it does.  It promises more than is actually eneded.  But, until we
have a way to describe what's needed precisely enough, we will have to
go with the stronger promise.

>> membar_sync
>>      All loads and stores preceding the memory barrier will complete
>>      and reach global visibility, respectively, before any loads and
>>      stores after the memory barrier start and reach global
>>      visibility, respectively.
> That works for me as long as you don't actually expect the CPU to
> complete the loads before the barrier before the loads after the
> barrier start.

Given that wording, I certainly do, because that's what it promises.
If you prefer a weaker wording, feel free to suggest it, but make sure
it actually guarantees enough to be useful, or there's no point having
the operation at all.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B