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

[Richard O'Keefe]

I'm aware of try_take/4.  The significant thing about
thread.mvar.try_read/4 is that it does not change the state of the
mvar in question, and if you just want to *test* whether a channel is
empty or not, that's what you want.

My Smalltalk implementation of SharedQueue (the Smalltalk analogue of
thread.channel) needs one POSIX lock and one POSIX condition.
OpenJDK's java.util.concurrent.LinkedBlockingQueue uses two locks and
two conditions.  (And LinkedBlockingQueue provides a .size()
operation, together with a warning against trusting it.)

On Mon, 6 Nov 2023 at 17:23, Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Montag, dem 06.11.2023 um 14:28 +1300 schrieb 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.
>
> Yeah. That occurs to me, too.
>
> > 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.
>
> Yes.
>
> > 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.
>
> Yes, that's what I mean.
>
> > 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,
>
> There's thread.channel.try_take/4.
>
> > but I've now had two
> > goes at it, and
> > was wrong both times.
> >
> > Surely a lighter-weight thread.channel is possible and desirable?
>
> I don't know if it's possible, but 2N+4 semaphores sounds really heavy...
>
> Still, for the application, which I have in mind, it shouldn't matter. There
> are worker threads, which stat files, calculate hashes, communicate with a
> database and such. So the channel implementation shouldn't carry weight.
>
> Cheers
> Volker
>
> >
> >
> > 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
>
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users