Date: Wed, 20 Jul 2022 12:55:21 +0500
On 20/07/2022 00:22, Marcin Jaczewski wrote:
> wt., 19 lip 2022 o 13:39 <language.lawyer_at_[hidden]> napisał(a):
>>
>> On 19/07/2022 16:28, Marcin Jaczewski wrote:
>>> But for `notify` explicitly say it NEED to do in that way that `wait`
>>> WILL see it correctly.
>>> The Definition of `wait` on its own is not enough, you need to read
>>> the whole standard and all cross references,
>>> like in the case of `memcpy` that all special guarantees are placed in
>>> multiple places of standard.
>>
>> I've re-checked the definition of notify, of wait and of "eligible to be unblocked" and still do not see how the visibility of the new value is guaranteed.
>> Could you be more concrete instead of reading morals?
>
> And how do I do anything else when you refuse to accept things that
> the standard says?
>
> Lets quote standard again:
> """
> A call to an atomic waiting operation on an atomic object M is
> eligible to be unblocked by a call to an atomic notifying operation on
> M if there exist side effects X and Y on M such that
> - the atomic waiting operation has blocked after observing the result of X,
> - X precedes Y in the modification order of M, and
> - Y happens before the call to the atomic notifying operation.
> """
> First observation is that there is NO direct ordering between waiting
> and notifying. It looks like it should work even if `notify` is
> strictly BEFORE the block.
> This mean we could have sequence:
>
> Thread1 //--// Thread2
> store(M, false) //--//
> ...
> ...
> load(M) == false //--//
> //--// store(M, true)
> //--// notify(M)
> block(M, false) //--//
>
> `block` is eligible for unblocking as it fulfills every point there.
> Thread1 blocked after observing the old value `false`, Thread2 changed
> `M` to `true` and then called `notify`.
> Nothing prevents `notify` to unlock future `block` as only the
> proceeding of modification of `M` is required.
> And this could be implemented by sleeping for 1s in `notify` to give
> time to all `block` correctly registered.
And how all this resolves the initial concern that a thread is not guaranteed to see the new value after unblock and thus will block again?
> wt., 19 lip 2022 o 13:39 <language.lawyer_at_[hidden]> napisał(a):
>>
>> On 19/07/2022 16:28, Marcin Jaczewski wrote:
>>> But for `notify` explicitly say it NEED to do in that way that `wait`
>>> WILL see it correctly.
>>> The Definition of `wait` on its own is not enough, you need to read
>>> the whole standard and all cross references,
>>> like in the case of `memcpy` that all special guarantees are placed in
>>> multiple places of standard.
>>
>> I've re-checked the definition of notify, of wait and of "eligible to be unblocked" and still do not see how the visibility of the new value is guaranteed.
>> Could you be more concrete instead of reading morals?
>
> And how do I do anything else when you refuse to accept things that
> the standard says?
>
> Lets quote standard again:
> """
> A call to an atomic waiting operation on an atomic object M is
> eligible to be unblocked by a call to an atomic notifying operation on
> M if there exist side effects X and Y on M such that
> - the atomic waiting operation has blocked after observing the result of X,
> - X precedes Y in the modification order of M, and
> - Y happens before the call to the atomic notifying operation.
> """
> First observation is that there is NO direct ordering between waiting
> and notifying. It looks like it should work even if `notify` is
> strictly BEFORE the block.
> This mean we could have sequence:
>
> Thread1 //--// Thread2
> store(M, false) //--//
> ...
> ...
> load(M) == false //--//
> //--// store(M, true)
> //--// notify(M)
> block(M, false) //--//
>
> `block` is eligible for unblocking as it fulfills every point there.
> Thread1 blocked after observing the old value `false`, Thread2 changed
> `M` to `true` and then called `notify`.
> Nothing prevents `notify` to unlock future `block` as only the
> proceeding of modification of `M` is required.
> And this could be implemented by sleeping for 1s in `notify` to give
> time to all `block` correctly registered.
And how all this resolves the initial concern that a thread is not guaranteed to see the new value after unblock and thus will block again?
Received on 2022-07-20 07:55:27