On 09/05/18(Wed) 13:07, Paul Irofti wrote:
> On Wed, May 09, 2018 at 11:33:06AM +0200, Martin Pieuchot wrote:
> > On 09/05/18(Wed) 11:43, Paul Irofti wrote:
> > [...]
> > Then the writer uses atomic operations to increment/decrement `waitcount'
> > but is it enough to have the reader, see the updated value?
>
> On x86 I think it is guaranteed. Not sure about others or if we need
> membars here too. Visa said membars are not needed in this case for
> mips.
Good, what about other archs?
> > What if the
> > check is done before the atomic operation has been performed?
>
> Then we should probably wrap the for (;;;) loop in atomic increments and
> decrements.
That's would be better, but then...
> atomic_inc_int(&sem->waitcount);
> for (;;) {
> while ((v = sem->value) > 0) {
> ov = atomic_cas_uint(&sem->value, v, v - 1);
> if (ov == v) {
> membar_enter_after_atomic();
^^^^^
...don't forget to break or decrease `waitcount' here :)
> return 0;
> }
> }
> if (r)
> break;
>
> r = _twait(&sem->value, 0, CLOCK_REALTIME, abstime);
> /* ignore interruptions other than cancelation */
> if ((r == ECANCELED && *delayed_cancel == 0) ||
> (r == EINTR && !can_eintr) || r == EAGAIN)
> r = 0;
> }
> atomic_dec_int(&sem->waitcount);
>
>
> > Worst
> > what if the cache of the reader doesn't contain the last value?
>
> The way to be absolutely sure is to also do an atomic operation when
> reading the waitcount in sem_destroy.
>
> If we decide to be that paranoid, we should do the same for
> sem_getvalue() :)
I'd prefer if we could teach each other how stuff really work :o)
