From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Chow Subject: Re: locking techniques . Date: Thu, 17 Jul 2003 22:52:32 +0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3F16B830.7050908@shaolinmicro.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from [202.94.238.145] ([202.94.238.145]:47835 "EHLO mail.shaolinmicro.com") by vger.kernel.org with ESMTP id S271466AbTGQOhu (ORCPT ); Thu, 17 Jul 2003 10:37:50 -0400 To: Nir Tzachar List-Id: linux-fsdevel.vger.kernel.org > > >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