On 2/1/06, Prabhat Hegde <pubs.hegde@xxxxxxxxx> wrote:
when a process tries to lock a spin lock that is already locked it'll consume it's time quantum spinning in a tight loop as you've said. the CPU won't be aware of the situation and it'll think that the process is doing a useful job .. so it'll leave the process executing ..
when you talk about a semaphore .. them trying to acquire a semaphore that has the zero value then this will cause the process state to be changed from the runnable to the interruptable (actually this is the case when using "down_interruptable") .. this means that the processes will be scheduled and won't be chosen for executing again until it's back to the runnable state i.e. until someone calls "up" on the semaphore .. this way the process won't get the CPU until it has something to execute .. and this way the CPU time is not wasted ..
Hi,Thanks for the aid.> I don't understand, what do you mean by "in case of memory"?Actually i wanted to know as to what happens to a process when it is executing in user context and interrupt context? Can the memory held by a process while it is executing in interrupt context be swapped out? This was my doubt regarding "in case of memory"
> In general, spin lock is actually a busy loop, while semaphore makes
> you sleep if the lock can't be obtainedSo how different is spin lock? Cos the process seeking the lock will keep spinning on the lock in a tight instruction loop. So in this case also the process is held up as it keeps spinning around the lock. How different is this from sleeping? Wont that CPU runnig the process that is waiting for the lock do some other work? But if spin_try_lock() is used, then thats a different case.
when a process tries to lock a spin lock that is already locked it'll consume it's time quantum spinning in a tight loop as you've said. the CPU won't be aware of the situation and it'll think that the process is doing a useful job .. so it'll leave the process executing ..
when you talk about a semaphore .. them trying to acquire a semaphore that has the zero value then this will cause the process state to be changed from the runnable to the interruptable (actually this is the case when using "down_interruptable") .. this means that the processes will be scheduled and won't be chosen for executing again until it's back to the runnable state i.e. until someone calls "up" on the semaphore .. this way the process won't get the CPU until it has something to execute .. and this way the CPU time is not wasted ..
> which cache? L1/L2 cache? page cache? internal disk cache?
well actually all of them as i dont have much knowledge as to what role each one plays.in reply for:I have doubt in the following areas. Can anyone throw some ligt on it:
1. What is the difference between interrupt context & user context in
case of memory. (user space & kernel space related)
2. How internally a spinlock is different from a semaphore?
3. Cache coherence in linux 2.6 kernels? (detailed explaination is
greatly appreciated)
