Mark H Weaver <m...@netris.org> writes:
> Here's what experiment shows:
>
> scheme@(guile-user)> (use-modules (ice-9 mvars))
> scheme@(guile-user)> (define mv (new-empty-mvar))
> scheme@(guile-user)> (define producers
> (map (lambda (i)
> (usleep 200000)
> (call-with-new-thread
> (lambda ()
> (let loop ()
> (put-mvar mv i)
> (loop)))))
> (iota 10)))
> scheme@(guile-user)> (map (lambda (_) (take-mvar mv)) (iota 100))
> $1 = (0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
> 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8)
>
> I confess that I do not yet understand why the first thread was able to
> put the first two values into the MVar
I see now why that happened. The first thread was able to immediately
put the first 0 into the MVar without waiting, and then became the first
entry in the wait queue to put the second 0, before the second thread
started waiting to put the first 1.
So, the experiments are perfectly consistent with my understanding from
looking over the code in threads.c, that Guile's mutexes and condition
variables have a FIFO policy for waiting threads. Therefore my MVar
implementation also has a FIFO policy, and therefore meets the fairness
requirements.
Mark
