All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.