Hi,
I deal with devices (i2c bus, flash memory), which are quite slow,
i.e. some or mostly all operations on it are quite slow. One must wait
for it for rather long time. Use of DELAY() is too expensive and an
inactive (so called unbound) wait isn't permited with mutexes. So, no
priority propagation locking primitive could be exploited.
Typical simple operation (which must be locked) is following:
HW_LOCK
write request (fast)
wait for processing (quite slow)
read response (fast)
HW_UNLOCK
Here, use of mutex with mtx_sleep() is impossible, as mutex is
unlocked during (unbound) sleep and somebody can start new operation.
An response which is read after sleep could be incorrect.
Well, I deal with a hardware, so all sleeps on it could be infinite.
It's driver writer responsibility to ensure that all situations which
can lead to infinite waits are treated correctly and can't happen. The
waits (if no error happen on hardware, what must be treat anyway)
could be rather long (but with known limits from specification). Long
but not unbounded.
I lack of a locking primitive with priority propagation on which
inactive waits are permited. I'm not too much familiar with locking
implementation strategy in FreeBSD, but am I one and only who needs
such a lock? Or such lock is not permitted for really good reasons?
Well, I know that only KASSERT in mtx_init() (mutex can't be made
SLEEPABLE) and witness in mtx_sleep() (can't sleep on UNSLEEPABLE
locks) quard the whole stuff. But should I hack it and use mutex as a
locking primitive I need? (Of course, I will always use it with
timeout.)
Thanks for any response,
Svata
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
