Re: Thread locks in 10.3
Re: Thread locks in 10.3
- Subject: Re: Thread locks in 10.3
- From: Terry Lambert <email@hidden>
- Date: Thu, 19 Oct 2006 13:19:43 -0700
On Oct 19, 2006, at 3:42 AM, Quinn wrote:
At 13:53 -0400 18/10/06, Carl Smith wrote:
I guess in retrospect I could some direction where to read up on
the 10.4 locking design. If anyone knows where I could find this
document and or some examples I would appreciate it.
One key thing to remember is that the Mac OS X locking design varies
by kernel subsystem.
o Mach has always had fine grained locking
o BSD (specifically the file system and networking subsystems) used
funnels until Mac OS X 10.4, whereupon they switched to fine grained
locking
o I/O Kit locking is based on the workloop model
A minor correction...
As of 10.4, there are still 84 system calls out of 369 system call
slots that continue to use the kernel funnel as a protection
mechanism. Some of these are SPI rather than API, meaning that they
are not intended for third party use, and are merely implementation
details for API that's exposed by Libc or some other framework. Most
of them deal with signals and process management, so there's not a lot
you can do to stub your toe there.
If you look at the published source code for xnu/bsd/kern/
syscalls.master, the locking model is indicated in the third column.
So if you are writing code that lives under one of those system calls,
the funnel is expected; otherwise, the locking moves to data object
locking.
The major exposure point here is third party sysctl's and fsctl's,
since all of sysctl() and fsctl() operations currently take place
under the funnel.
You must also take this into account when implementing a device driver
that implements a select() (including for kqueue()) entry point, or if
your KEXT intends to do something during the reboot() process (e.g.
for processing SIGTERM to the user space process that happens prior to
actual shutdown), since all of reboot(0 happens under the funnel.
Finally, if you implement a KAUTH listener, you may listen for things
which happen under the funnel (e.g. execve(), etc.), so where
possible, make your code not care about whether or not the funnel is
held, or if you can't do that, there's examples in bsd/kern/
kern_newsysctl.c and bsd/kern/kern_sig.c on how to use
thread_funnel_get() to decide to take the funnel if it's not already
held, and drop it if you took it, before returning.
Otherwise, if you stay within the published KPI for your KEXT, you
should pretty much be immune from and changes to the model that may or
may not happen in software updates or future releases.
If you don't stay within the published KPI (Kernel Programming
Interface) for your KEXT, then expect to be surprised, since we
reserve the right to change the locking model on what we believe are
non-exposed objects and code paths in future releases (in fact, this
has already happened several times in software updates to 10.4, to
address various performance and other issues; mostly, no one has
noticed).
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden