* locking techniques .
@ 2003-07-13 8:33 Nir Tzachar
2003-07-17 14:52 ` David Chow
0 siblings, 1 reply; 2+ messages in thread
From: Nir Tzachar @ 2003-07-13 8:33 UTC (permalink / raw)
To: linux-fsdevel
Hi all.
I have a question regarding locking techniques:
Lets say I have a lengthy create ( or any other inode->i_op operation ).
Is it considered good practice to release all locks im holding while in
inode->i_op->create ( and reacquire them later .. ) ???
I've seen this done in intermezzo, but are there more implication than an
untrained mind can notice ????
cheers ;)
========================================================================
nir.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: locking techniques .
2003-07-13 8:33 locking techniques Nir Tzachar
@ 2003-07-17 14:52 ` David Chow
0 siblings, 0 replies; 2+ messages in thread
From: David Chow @ 2003-07-17 14:52 UTC (permalink / raw)
To: Nir Tzachar; +Cc: linux-fsdevel
>
>
>I have a question regarding locking techniques:
>Lets say I have a lengthy create ( or any other inode->i_op operation ).
>Is it considered good practice to release all locks im holding while in
>inode->i_op->create ( and reacquire them later .. ) ???
>I've seen this done in intermezzo, but are there more implication than an
>untrained mind can notice ????
>
>cheers ;)
>========================================================================
>nir.
>
>
If you are using spinlocks, you shoudn't sleep during the operation.
Even you don't sleep, you have to make sure all functions in the path
between unlock doesn't sleep. This is because sleeping can make other
task to run and "may " acquire the same lock and eventually dead lock.
This case you should use semaphore which is safe to sleep during holding
the lock. If you planned to release the lock, you just have to make sure
your resources are sychronized properly even no lock. In a create
operation, likely you will need to lock to some resources (maybe to
avoid other create process being creating the same thing on the same
resource) until the creation is completed. If you don't want to hold the
CPU for long, you should use semaphore instead of spinlock for that lock
such that you can sleep during the creation process. Sleep here means
letting other tasks to run by explicitly calling schedule(). If you
sleep, your CPU will be schedule to run other tasks such that the system
will not be blocked in your current task until other tasks trying to
acquire the same lock (will wait for that locked lock). If you plan to
release the lock, likely you will not able to acquire the same lock
state after some time if you sleep (or if you are on smp, other tasks
can run as well). Anyway, it doesn't make sense to release any locks if
locking is necessary during any long operation, unless the lock is
useless and of course you don't want to hold it this case. May be you
should read more docs about Linux scheduling or you may want to read
about document about locking. There are something relavant in the
www.kernelnewbies.org called "Unreliable guide to locking" .
regards,
David Chow
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-07-17 14:37 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-13 8:33 locking techniques Nir Tzachar
2003-07-17 14:52 ` David Chow
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.