Re: Trylocks in the kernel
Re: Trylocks in the kernel
- Subject: Re: Trylocks in the kernel
- From: Ryan McGann <email@hidden>
- Date: Tue, 13 Dec 2005 21:58:12 -0800
On Dec 13, 2005, at 9:44 AM, Josh Graessley wrote:
It's not that you can't block in your data in filter. You want to
be careful about what you block on and how long it is likely to be
blocked.
For example, if you were to take a lock where you enqueue data and
then drop it, that would be fine as long as the only other code
taking the lock is something that takes the lock to dequeue the
data so it can process it after dropping the lock.
Thanks for this clarrification Josh. I don't feel so bad now taking
the lock, since it should never be locked for more than a couple
milliseconds (worse case). It still would be nice to have a trylock
though.
An example of a bad place to block would be writing the data out
another socket to a user process and waiting for a response.
Another bad example would be attempting to take a lock that some
other piece of code holds while calling in to the network stack to
perform an operation that may block. You need to evaluate the other
places where the lock you will be taking is held and make sure that
lock isn't held while some other long term or interdependent
operation is performed. Doing so may lead to deadlocks.
I take the lock inside of dataIn and dataOut to protect access to my
queue of buffered data. I take it also when I need to reinject the
code. As long as sock_reinject_* doesn't block, all of the statements
you made about my code should hold. Basically I need to do the same
thing as the tcplognke sample, and I see that sample takes a mutex
inside of dataIn as well. I don't feel bad now :-)
Thanks,
Ryan
On Dec 12, 2005, at 10:23 PM, Ryan McGann wrote:
The new Tiger locking KPIs seem to lack a trylock variant for any
of the lock types (mutex, spinlock, read/write). I'm trying to
figure out how to get around this. I need to take a read-write
lock in a socket filter dataIn callback, but of course you cannot
block inside dataIn for any length of time. So I _was_ going to
use a trylock, and if I failed to get the lock, just bail out. But
it looks like the only way to accomplish what I want to do is to
use lck_rw_sleep_deadline.
However I'm not exactly sure of the semantics of this API. If I
give it a deadline of "now", will it still perform a context
switch regardless of whether the lock is taken or not? I don't
want the expense of a context switch if the lock isn't even going
to be taken.
Is there any way of duplicating the behavior of a trylock using
the Tiger KPIs? Or am I stuck using lck_rw_sleep_deadline? And can
that API context switch on me without taking the lock?
Thanks,
Ryan
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden