Threading in IOKit (was: Protection Questions)
Threading in IOKit (was: Protection Questions)
- Subject: Threading in IOKit (was: Protection Questions)
- From: Godfrey van der Linden <email@hidden>
- Date: Mon, 3 Jun 2002 14:51:50 -0700
Basically there are two locking mechansims you will need to worry about.
One is the IOWorkLoop you are slaved against, that is the workloop of
the USB controller. The second lock is the network funnel. In
general you will not have to worry about the funnel as the
IONetworkingFamily will handle most of that for you.
Now to address some of your questions.
In X you don't get anything at Primary interrupt time, so that is
easy (Note PCI device do have access to the primary interrupt through
the IOFilterInterruptEventSource but you are a USB device so you
don't have to worry about that.
All USB completions come on the USBs IOWorkLoop and thus holds the
gate. If you wish to synchronise a 'down' call against your
completions you can do this by creating your on IOCommandGate and
registering it against your work loop. You get the correct work loop
to use by call IO
Service::getWorkLoop() on yourself so that is pretty
easy. getWorkLoop() automatically walks down your provider chain
looking for a driver that exports the completion context, the USB
controller in your example.
Timers also synchronise against the work loop when you use the
IOTimerEventSource. However there is a long outstanding bug against
the IOTES where it doesn't have a deterministic way of cancelling at
the moment. If you wish to shut down a driver and still have a timer
outstanding it is usually better to just wait for the last timeout to
occur rather than attempting to cancel it. (yes I have had this bug
for a long time and the fix is pretty easy but I have a long list of
other very high priority problems to fix first).
Now there are a couple of X subtleties that 9 didn't have.
Provided you use the work loop paradigm then it is easy to
synchronise against all callouts and also easy to keep down calls
correct by using your own command gate. But you do have to watch out
for blocking calls. It is probably never correct to issue a call
that can block indefinitely while in a gated context. However short,
(how short is undefined?) delays acceptable, hence it is ok to use
locks on a work loop context but it is better if you don't need to.
Also you have to watch out for various scheduling priorities.
Broadly we have
1> Primary Interrupts
2> Real Time Threads (user land only)
3> Timer threads (Thread Call threads, kernel only)
4> Kernel threads (IOWorkLoop aka 'secondary interrupts')
5> Window Manager Threads
6> The rest of user land threads.
Sometimes the priorites seems a bit screwed up, for instance a
timeout will schedule before a secondary interrupt, but provided you
know this can occur it is pretty easy to write a timeout routine that
checks to see if the hardware has completed or not.
Finally Scott I have been meaning to write up this stuff for a while.
In fact I have twice unsucessfully asked for a WWDC session to cover
it in detail (I failed in both cases 'cause I was too late and there
was no time left). Anyway why don't we use this email conversation
as a way of getting on the record?
Godfrey van der Linden
(The inflictor of IOWorkLoop on a poor unsuspecting world)
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.