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