Re: kernel condvars: how to use?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> If anything, you should just test rather whether you changed from a
>>> state that would block a read to a state in which a read can make
>>> progress.
>> That's kind-of what LPT_RF_WAITING records.
> What I meant is the condition that read actually loops on.  [...]

Yes, that's what I thought you meant.  But...

> If read does

> 	while (sc->sc_foo < sc->sc_bar)
> 		cv_wait(&sc->sc_cv, &sc->sc_lock);

> then whoever changes sc_foo or sc_bar might test whether they changed
> from sc->sc_foo < sc->sc_bar to !(sc->sc_foo < sc->sc_bar) before
> they cv_broadcast.

...then you have the same test in two places, leaving them vulnerable
to one but not the other being changed.  (Of course, only some changes
will break functionality, but that's a separate issue.)

Furthermore, they and LPT_RF_WAITING are testing/describing different
things: "is anyone actually waiting?" versus "if anyone does happen to
be waiting, could this make a difference?".  (Each one is a useful test
under some circumstances; it just seems to me that, while each can be a
useful test to apply there, confusing the tested-for conditions is
likely to lead to muddy thinking and thence muddy code.)

>> Looking at the implementation of __insn_barrier(), it looks like
>> overkill: is forces _everything_ out of registers, [etc].  Using
>> volatile does so only for the things for which it actually matters
> Yes, that's right.  On the other hand, volatile also applies to every
> access to fields in question, whereas __insn_barrier applies a
> barrier only in one specific place.

That's why I write

	struct lpt_softc *sc;
	volatile struct lpt_softc *vsc;

	vsc = sc;

and use vsc-> when volatile is appropriate and sc-> when not.

It would be better if C provided a way to mark a sequence point as
volatile-synchronizing, relaxed (as compared to the current rules) so
that object accesses are synchronized not as of the next sequence point
but rather as of the next _marked_ sequence point.  Possibly, instead,
a way to name objects and force their values to be synchronized.  But
we don't have either, and, with no namespace for sequence points (many
of which have no explicit textual representation in the source), I'm
not sure how doable the former would be.

> In any case, neither __insn_barrier nor volatile is sufficient in the
> multiprocessor model,

Not sufficient, true, but necessary (though, depending on the
implementations of things like C and mutexes, possibly implicitly
provided).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B