Sorry if you don't want to be bothered with my problems, but I think this
problem which I've just encountered is rather amusing. Is there a neat solution?
I confess to finding concurrency problems difficult so there might be.
I want to implement a type Flag. Each flag is either Up or Down.
Tom Pledger writes:
[...]
Something along these lines:
But without the bug and the eccentricities. :-(
[...]
wasDown2 - sag flag2
This just moved the deadlock. Instead of doing a busy wait for a
non-sagging flag2, we must put flag1 back up and try again from the
beginning
George Russell wrote:
The problem is that lowerFlags should appear to be atomic, so that
if lowerFlags is called simultaneously in different threads, the result
should be the same as if one of the calls completed before the other started.
If you want lowerFlags to be atomic, in the global
George Russell wrote:
What is the neatest solution? There is an obvious solution, which is to
crudely sequence all calls to lowerFlags by making them lock a single
global variable (created using, sigh, unsafePerformIO) but this doesn't seem very
elegant. If MVar's were instances of Ord as
I am attempting to learn to use ghc's profiling utilities. I successfully
compiled a program (without using -prof) that used the ListUtils
library. When i went back to try and profile this program i did something
like
/ghc -c -O -prof -auto ListUtils.hs
and got an error message to the effect of
Michael Hobbs wrote:
(We're assuming that we can't lock them both simultaneously)
I knew I should have read the literature on deadlock avoidance before
posting that message. :-/ In fact, I should have used the word
"atomically" above instead of "simultaneously". As it turns out, I
believe that
Michael Hobbs wrote:
Here's my stab at it. (NB: This is simply an off-the-cuff attempt. It
looks like it should work right, but it is far from rigorously tested or
analyzed.)
grumble/
I discovered a path that would cause a deadlock in that code as well.
However, I have a change that /should/
