Test and test-and-set: Difference between revisions

Content deleted Content added
top: Explain the reason why we need test and test and set over test and set.
mNo edit summary
Line 2:
[[mutual exclusion]] in [[multiprocessor]] environments. Although a correct [[lock (computer science)|lock]] can be implemented with test-and-set, it can lead to [[resource contention]] in busy lock (caused by bus locking and cache invalidation when test-and-set operation needs to access memory [[atomic (computer science)|atomically]]).
 
To lower the overhead a more elaborate locking protocol '''test and test-and-set''' is used. The main idea is to reduce [[writeback]] that can create [[resource contention]] when two seperateseparate threads want the same lock. If ''n'' threads are competing for the lock, they will attempt to acquire it as soon as it is released if only using [[test and set]], causing each thread to invalidate the lock flag, meaning it must be propagated through the cache of the remaining processors ''n'' times, before any one thread may safely read it. By adding the ''check-yield'' step, only the first thread of execution to notice the lock is free will atemptattempt to obtain it, eliminating the writeback.
To lower the overhead a more elaborate locking protocol '''test and test-and-set'''
is used. The main idea is to reduce [[writeback]] that can create [[resource contention]] when two seperate threads want the same lock. If ''n'' threads are competing for the lock, they will attempt to acquire it as soon as it is released if only using [[test and set]], causing each thread to invalidate the lock flag, meaning it must be propagated through the cache of the remaining processors ''n'' times, before any one thread may safely read it. By adding the ''check-yield'' step, only the first thread of execution to notice the lock is free will atempt to obtain it, eliminating the writeback.
 
''boolean'' locked := false ''// shared lock variable''