public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chow <davidchow@shaolinmicro.com>
To: Nir Tzachar <tzachar@cs.bgu.ac.il>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: locking techniques .
Date: Thu, 17 Jul 2003 22:52:32 +0800	[thread overview]
Message-ID: <3F16B830.7050908@shaolinmicro.com> (raw)
In-Reply-To: Pine.LNX.4.44_heb2.09.0307131123420.12905-100000@ruby

>
>
>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


      reply	other threads:[~2003-07-17 14:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-13  8:33 locking techniques Nir Tzachar
2003-07-17 14:52 ` David Chow [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F16B830.7050908@shaolinmicro.com \
    --to=davidchow@shaolinmicro.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tzachar@cs.bgu.ac.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox