Hi Wendy,
It looks like no one responded to this question, so I'll take a stab.
Your question is about:
"Do not use a mutex to set driver state. However,
you should use a mutex to protect driver state
data."
in the mutex(9f) man page?
Generally, you initialize (set) driver state for a given instance of the device
in the attach function, which should be single-threaded for the instance being
initialized. You don't need mutexes for data that is being initialized while
you are single threaded.
(You also don't need mutexes for data that is never changed after being initialized, assuming the initialization is done where you are single-threaded).
However, anywhere you have global data that may be accessed (and modified) at the same
time, you should protect that data. Even on a single processor machine, interrupts or kernel preemption (for real-time) can cause a different thread to access/modify the data, so you should protect that data, (i.e., you should not use ifdef's to include/exclude mutexes).
Note that if you have global data that is used
across instances of the device, you would typically initialize that data in the
_init(9f) function along with a mutex(es) for that data. (_init should be
single threaded for the driver). If you then access/modify that cross-instance
data in attach, you would need to protect that data in attach.
I think the sentence in the manual page could be more clear...
max
wendy wrote:
Hi,
Below is the man page of mutex, can someone explain what does the black words
mean? many of my colleagues are confused. Does it mean that for driver state,
we are free to change? then how do we protect it?
Wendy
mutex(9F)
Acquiring a lock in user context that is also
acquired in interrupt context means that, as long
as that lock is held, the driver instance holding
the lock is subject to all the rules and limita-
tions of interrupt context.
In most cases, a mutex can and should be acquired
and released within the same function.
Liberal use of debugging aids like
ASSERT(mutex_owned(&mutex)) can help find callers
of a function which should be holding a mutex but
are not. This means you need to test your driver
compiled with DEBUG.
[b]Do not use a mutex to set driver state. However,
you should use a mutex to protect driver state
data.[/b]
Use per-instance and automatic data where possible
to reduce the amount of shared data. Per-instance
data can be protected by a per-instance lock to
improve scalability and reduce contention with
multiple hardware instances.
Avoid global data and global mutexes whenever pos-
sible.
SunOS 5.9 Last change: 16 Mar 2003 4
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
