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

[Volker Wysk]

Am Montag, dem 06.11.2023 um 20:29 +1300 schrieb 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.

Yes, this would be good to have for channels...

> 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.)

That sounds better. :-)

> 
> 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