Hi Gaurav, Thank you for your detailed reply. Some comments appear below. On 2/7/06, Gaurav Dhiman <gauravd.chd@xxxxxxxxx> wrote: > I dont think you need to use the global falg variable to sync the > access to shared data structure; INTERRUPTED or IN_PROGRESS flags. > This sync can be handled directly by spinlock which you use to sync > the access to global flag variable. > > So remove the flag variable and directly sync the access with spinlock. I used the flag variable as an example. Basically, if sys_foo() gets holds of the spin lock first, then it sets the flag (which is embedded elsewhere; it is rather fine grain and not as coarse grain as I've mentioned) to FOO_IN_PROGRESS (among states the flag can be in). In due course, sys_foo(), will release the lock, perform operations that sleep and grab it again, so on and so forth and finally it will set the flag to FOO_COMPLETED while holding the lock and soon after which it will release the spin lock. Now once sys_foo() releases the lock, and the flag isn't set to FOO_COMPLETED as yet, so when the lock the grabbed in interrupt context, the code there checks to see if FOO_IN_PROGRESS has been set. If it has, then it sets the FOO_ABORT_INTERRUPTED flag and goes away. But if the timer code, gets the lock first, then it does a bunch of (non-sleeping) stuff on the shared data, sets the status to FOO_ABORT_COMPLETED and releases the lock. So now, when sys_foo() gets called, it sees this new state and does something else. Summary: If sys_foo() is in progress (after it has grabbed the spin lock for the first time and FOO_ABORT_COMPLETED) the timer interrupt code musn't do certain things. If sys_foo() hasn't started yet, then the timer interrupt can do certain other things and as a consequence sys_foo() must do certain other things. Thanks! Hareesh -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
