One of the methods resolving the situation is using a lock, such as spin lock. A spin lock is a lock that can be held by at most one thread of execution. in case a thread attempts to acquire a spin lock while it is already held by other thread, the attempting thread would get busy loops spins, waiting for the lock to get released by the thread which is in the critical section. This way we prevent that no more than one thread of execution enters the critical region at any one time.
The fact that a spin lock causes threads to spin until the lock would become available, is responsible for wasting processor time. Because of the spin lock’s nature it isn’t recommended to use it while knowing the lock would be held for long term of time. Spin lock should be held only for short durations.
Because they avoid overhead from operating system process rescheduling or context switching, spinlocks are efficient if threads are likely to be blocked for only short periods
So Let’s see The kernel’s Spin lock methods: Spin lock is architecture–dependent and implemented in assembly.such implementation is possible only with special assembly-language instructions, such as atomic test-and-set operations, and cannot be easily implemented in programming languages not supporting truly atomic operations.
Take a look at the interfaces as defined in: linux/spinklock.h , Here is a simple example:
DEFINE_SPINLOCK(mr_lock); spin_lock(&mr_lock); /* Critical section */ spin_unlock(&mr_lock);
For summing up the spinning behavior is optimal for short hold times and code that cannot sleep, such as interrupt handlers. It's illegal to schedule, preempt, or sleep on a wait queue after acquiring a spinlock. In cases were sleep time might be long or you potentially need to sleep while holding the lock, semaphore is a more suitable solution.
No comments:
Post a Comment