The solution to the ABA problem is to never reuse A. In a garbagecollected environment such as Java or .

NET, this is simply a matter of not recycling nodes. That is, once a node has been popped, never push it again. Instead allocate a fresh node. The garbage collector will do the hard wor of chec ing that the memory for node A is not recycled until all e!tant references to it are gone. In languages with garbage collection, the problem is harder. An old techni"ue dating bac to the IB# $%& changes ABA to ABA. In other words, ma e A slightly different each time. Another solution is to build a miniature garbage collector that handles pointers involved in compare' e!change operations. These pointers are called ha (a rd pointers, because they present a ha(ard to loc less algorithms.

CACHE LINE PING-PONGING)

Non'bloc ing algorithms can cause a lot of traffic on the memory bus as various hardware threads eep trying and retrying to perform operations on the same cache line. To service these operations, the cache linebounces bac and forth * ping'pongs+ between the contending threads. A loc ed algorithm may outperform the non'bloc ing e"uivalent if loc contention is sufficiently distributed.E!perimentation is necessary to find out whether the non'bloc ing or loc ed algorithm is better. A rough guide is that a fast spin loc protecting a critical section with no atomic operations may outperform an alternative non'bloc ing design that re"uires three or more highly contended atomic operations.

MEMORY RECLAMATION PROBLEM)

#emory reclamation is the dirty laundry of many non'bloc ing algorithms. ,or languages such as -.-// that re"uire the programmer to e!plicitly free memory, it turns out to be surprisingly difficult to call free on a node used in a non'bloc ing algorithm. The problem occurs for algorithms that remove nodes from lin ed structures, and do so by performing compare'e!change operations on fields in the nodes. ,or e!ample, non'bloc ing algorithms for "ueues do this. The reason is that when a thread removes a node from a data structure, without using a loc to e!clude other threads, it never nows if another thread still loo ing at the node. The solution is to use a garbage collector or mini'collector li e ha(ard pointers. Alternatively you may associate a free list of nodes with the data structure and not free any nodes until the data structure itself is freed.

RECOMMENDATIONS:
Non'bloc ing algorithms big advantage is avoiding loc pathologies. Their primary disadvantage is that they are much more complicated than their loc ed counterparts. Non'bloc ing algorithms are difficult to verify. None!perts should consider the following advice) Atomic increment, decrement, and fetch'and'add are generally safe to use in an intuitive fashion. The fetch'and'op idiom is generally safe to use with operations that are commutative and associative. The creation of non'bloc ing algorithms for lin ed data structures should be left to e!perts. 0se algorithms from the peer'reviewed literature. Be sure to understand any memory reclamation issues. Avoid having more runnable software threads than hardware threads, and design programs to avoid loc contention.

Department CSE, SCAD CET

6.Explain the i !e "ith #e#$%& ' (a(he in $pen#p)

MEMORY ISS*ES: i. Bandwidth ii. iii.

1or ing in the cache #emory contention

+i, BAND-IDTH:
To conserve bandwidth, pac data more tightly, or move it lessfre"uently between cores. 2ac ing the data tighter is usuallystraightforward, and benefits se"uential e!ecution as well. ,or e!ample, 1hen declaring structures in -.-//, declare fields in order ofdescending si(e. This strategy tends to minimi(e the e!tra padding that the compiler must insert to maintain alignment re"uirements, as e!emplified.

3ome compilers also support 4pragma pac directives that pac structures even more tightly, possibly by removing all padding.

3uch verytight pac ing may be counterproductive, however, because it causes misaligned loads

Department CSE, SCAD CET