[m-users.] Two more predicates for dealing wih threads

[Richard O'Keefe]

Ah, I thought it might be for debugging.
Looking at thread.channel.m, if there are N items in a channel, there
are N+2 mvars.
And an mvar contains 2 semaphores.  And a semaphore is a fairly
heavyweight thing.
I was expecting channels to have 1 or 2 semaphores; 2N+4 is quite a lot.

The way I think about semaphores, the "value" of a semaphore is the
count if that
is positive, or the negation of the length of the queue of waiting
threads if it is not.
I don't think that notion of value *can* be implemented.  If you just
mean extracting
the counter field, that could be done easily enough for C and C#
grades.  I don't
think it can be done for the Java backend.

Looking again at thread.channel.m, we see that (number of writes -
number of reads)
is not stored and would have to be be computed by walking over mvar
"lists".  I don't
see any easy way to do it that would be guaranteed to give you a number that was
*ever* accurate.  A test for whether a channel is currently empty
might be doable,
an analogue of thread.mvar's try_read/4 maybe, but I've now had two
goes at it, and
was wrong both times.

Surely a lighter-weight thread.channel is possible and desirable?


On Mon, 6 Nov 2023 at 02:39, Volker Wysk <post at volker-wysk.de> wrote:
>
> Hi.
>
> Yes, you do have to always treat the answer as out of date. And include a
> big warning sign in the documentation. Of course the result won't say
> "something about the state of the world NOW".
>
> I haven't thought about that, when I wrote my message to this list. But it
> still could be useful to have those predicates. Sometimes an answer, that's
> (a little) outdated, can still be useful. It depends on the case.
>
> In my case, I wanted to better understand what's going on. If I have a bug
> or not. So it was intended for debugging messages.
>
> Cheers,
> Volker
>
> Am Montag, dem 06.11.2023 um 02:17 +1300 schrieb Richard O'Keefe:
> > What do these operations actually mean?
> > When you get an answer from operations like these,
> > you always have to treat that answer as out of date.
> > I had a time-of-check/time-of-use bug recently.
> > It was one of those "check if something exists,
> > allocate workspace, try to use it" bugs.  The kind
> > where you go "but that's IMPOSSIBLE.  The code
> > just *checked* that this thing existed, how could it
> > not exist, oh wait, this is concurrent...
> >
> > Is there any way to formulate these things so that
> > when a thread looks at the result, it tells the thread
> > something about the state of the world NOW?
> >
> > On Sun, 5 Nov 2023 at 23:28, Volker Wysk <post at volker-wysk.de> wrote:
> > >
> > > Hi!
> > >
> > > I'm playing with threads, and in order to better see what's going on,
> > > I'd like to have two more predicates:
> > >
> > > - One for thread.channel, which returns the current length of the channel.
> > > - One for thread.semaphore, which returns the current value of the
> > >   semaphore.
> > >
> > > It would be nice, if those could be added.  :)
> > >
> > >
> > > Cheers,
> > > Volker
> > > _______________________________________________
> > > users mailing list
> > > users at lists.mercurylang.org
> > > https://lists.mercurylang.org/listinfo/users
>
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users