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

[Volker Wysk]

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