Re: Trylocks in the kernel
Re: Trylocks in the kernel
- Subject: Re: Trylocks in the kernel
- From: Josh Graessley <email@hidden>
- Date: Tue, 13 Dec 2005 09:44:35 -0800
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.
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.
-josh
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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