I realized a little while after writing my previous message that I was probably
misinterpreting you. I was envisioning you using box-cas! on a box containing a
functional queue, so there would be no need to synchronize. You’d just pull the
queue out of the box, functionally update it, and use bo
> On May 24, 2020, at 02:10, Dominik Pantůček
> wrote:
>
> At first I was surprised that you are basically suggesting using
> spinlocks (busy-wait loops) instead of futex-backed (at least on Linux)
> fsemaphores. That is a waste of CPU time.
Performing CAS operations in a loop isn’t really dire
On 24. 05. 20 3:38, Matthew Flatt wrote:
> At Sat, 23 May 2020 18:51:23 +0200, Dominik Pantůček wrote:
>> But that is just where the issue is showing up. The real question is how
>> the counter gets decremented twice (given that fsemaphores should be
>> futures-safe).
>
> I found a configuration
At Sat, 23 May 2020 18:51:23 +0200, Dominik Pantůček wrote:
> But that is just where the issue is showing up. The real question is how
> the counter gets decremented twice (given that fsemaphores should be
> futures-safe).
I found a configuration that triggered the bug often enough on my
machine.
On 23. 05. 20 19:24, Matthew Flatt wrote:
> I'm not sure this is the problem that you're seeing, but I see a
> problem with the example. It boils down to the fact that futures do not
> provide concurrency.
>
> That may sound like a surprising claim, because the whole point of
> futures is to run
I'm not sure this is the problem that you're seeing, but I see a
problem with the example. It boils down to the fact that futures do not
provide concurrency.
That may sound like a surprising claim, because the whole point of
futures is to run multiple things at a time. But futures merely offer
bes
6 matches
Mail list logo
