Re: Locking in kernel across user space calls

On 15/05/07, Jim Wintermyre <email@hidden> wrote:

I know that locking is generally discouraged unless absolutely
necessary, and in our driver I have tried to keep locking to a
minimum, only using it where serialization is really needed.
However, recently a new synchronization issue has come up.

We have a framework used by our user apps to communicate with the
device.  The framework has an Init function which makes calls like so:

do some stuff
call driver (via userclient)
do more stuff
call driver
more stuff
call driver

The problem is that all the stuff in between the driver calls needs
to be serialized across user process instances (instances of our
framework), so the entire Init function needs to be serialized, not
just the driver calls.  In the past the Init calls have never
happened from multiple processes simultaneously, since you typically
launch one app, then the other etc.  But we now have a situation
where multiple running apps can need to reinitialize things at the
same time, and so this problem has shown up.

Is your user client code doing an "open", "close"? I mean is your sMethods set up to have an open and close user client call similar to < http://developer.apple.com/samplecode/SimpleUserClient/listing4.html>. Then you could take a page from < http://developer.apple.com/samplecode/SimpleUserClient/listing6.html> and from your user space code you could do:

if ( KERN_SUCESS == MyUserClientOpen(...) )
{

do some stuff
call driver (via userclient)
do more stuff
call driver
more stuff
call driver
MyUserClientClose()
}
else
{
// back off for a few seconds and try again? Timer? Make MyUserClientOpen() block until it gets a successful return?
}

If all of your user space processes access the user client code via the open/close then you should get the serialized access that you are looking for. Of course MyUserClientOpen() wouldn't block, you'd just get an error if someone else has your driver "open" so maybe this isn't a good solution for you.

Anyway someone did mention IOLockSleep() :-)

Cheers,
-H.