[cs63201] more on fairness

Mikhail Nesterenko mikhail at cs.kent.edu
Wed Sep 7 18:02:29 EDT 2011


> So I was looking up stuff on Weak/Strong fairness and I found these
> two definitions.(very close to yours in wording)
> 
> Strong Fairness: every process that is infinitely often enabled should
> be executed infinitely often in
> a state where it is enabled.

That's almost the same definition that I presented except they are
defining fairness with respect to a process and not an individual
guarded command.

> Weak Fairness: every process that is almost always enabled should be
> executed infinitely often.

I would say that this is a rather vague definition because it is
unclear what "almost always" means. The definition that I use is
precise.


> I think the wording I might be having trouble with is "executed
> infinitely often". Or maybe just "infinitely often".

"Executed infinitely often" means that the execution of the particular
guarded command occurs infinitely many times in the computation. Notice
that, as we discussed today, finite computations are always fair (both
strongly and weakly). Hence all discussion of fairness concerns
infinite computations only.

> Is this another wording for forever? This confuses me because you
> said that Strong Fairness would be on/off/on/off/on/off etc...

What I said that the particular case that distinguishes strong
fairness from weak fairness is a computation where a guarded command is
enabled then, later, disabled (by the execution of another guarded
command) then enabled again and so on infinitely. This particular case
applies to strong fairness but not weak fairness.

Now, just to reiterate, for the class on Monday, you all are thinking
about two questions:

- How to modify (with minimal number of changes) the shared memory
  program presented in class such that it allows a strongly unfair
  computation.

- if a computation is strongly fair, is it also weakly fair? Is
  the converse true?


Thanks,
--
Mikhail


More information about the cs63201 mailing list