Ttt

3
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 work of checking that the memory for node A is not recycled until all extant references to it are gone. In languages with garbage collection, the problem is harder. An old technique dating back to the IBM 370 changes ABA to ABA’. In other words, make A slightly different each time. Another solution is to build a miniature garbage collector that handles pointers involved in compare-exchange operations. These pointers are called ha za rd pointers, because they present a hazard to lockless algorithms. CACHE LINE PING-PONGING : Non-blocking algorithms can cause a lot of traffic on the memory bus as various hardware threads keep trying and retrying to perform operations on the same cache line. To service these operations, the cache linebounces back and forth (“ping-pongs”) between the contending threads. A locked algorithm may outperform the non-blocking equivalent if lock contention is sufficiently distributed.Experimentation is necessary to find out whether the non-blocking or locked algorithm is better. A rough guide is that a fast spin lock protecting a critical section with no atomic operations may outperform an alternative non-blocking design that requires three or more highly contended atomic operations. MEMORY RECLAMATION PROBLEM : Memory reclamation is the dirty laundry of many non-blocking algorithms. For languages such as C/C++ that require the programmer to explicitly free memory, it turns out to be surprisingly difficult to call free on a node used in a non-blocking algorithm. The problem occurs for algorithms that remove nodes from linked structures, and do so by performing compare-exchange operations on fields in the nodes. For example, non-blocking algorithms for queues do this. The reason is that when a thread removes a node from a data structure, without using a lock to exclude other threads, it never knows if another thread still looking at the node. The solution is to use a garbage collector or mini-collector like hazard pointers. Department CSE, SCAD CET

Transcript of Ttt

Page 1: Ttt

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 work of checking that the memory for node A is not recycled until all extant references to it are gone.

In languages with garbage collection, the problem is harder. An old technique dating back to the IBM 370 changes ABA to ABA’. In other words, make A slightly different each time.

Another solution is to build a miniature garbage collector that handles pointers involved in compare-exchange operations. These pointers are called ha za rd pointers, because they present a hazard to lockless algorithms.

CACHE LINE PING-PONGING: Non-blocking algorithms can cause a lot of traffic on the memory bus as various hardware threads keep

trying and retrying to perform operations on the same cache line. To service these operations, the cache linebounces back and forth (“ping-pongs”) between the contending

threads. A locked algorithm may outperform the non-blocking equivalent if lock contention is sufficiently

distributed.Experimentation is necessary to find out whether the non-blocking or locked algorithm is better. A rough guide is that a fast spin lock protecting a critical section with no atomic operations may outperform

an alternative non-blocking design that requires three or more highly contended atomic operations.

MEMORY RECLAMATION PROBLEM:

Memory reclamation is the dirty laundry of many non-blocking algorithms. For languages such as C/C++ that require the programmer to explicitly free memory, it turns out to be

surprisingly difficult to call free on a node used in a non-blocking algorithm. The problem occurs for algorithms that remove nodes from linked structures, and do so by performing

compare-exchange operations on fields in the nodes. For example, non-blocking algorithms for queues do this. The reason is that when a thread removes a node

from a data structure, without using a lock to exclude other threads, it never knows if another thread still looking at the node.

The solution is to use a garbage collector or mini-collector like hazard 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-blocking algorithms big advantage is avoiding lock pathologies. Their primary disadvantage is that

they are much more complicated than their locked counterparts. Non-blocking algorithms are difficult to verify. Nonexperts 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-blocking algorithms for linked data structures should be left to experts. Use 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 lock contention.

6.Explain the issue with memory & cache in openmp?

Department CSE, SCAD CET

Page 2: Ttt

MEMORY ISSUES:i. Bandwidth

ii. Working in the cacheiii. Memory contention

(i) BANDWIDTH: To conserve bandwidth, pack data more tightly, or move it lessfrequently between cores. Packing the data tighter is usuallystraightforward, and benefits sequential execution as well. For example, When declaring structures in C/C++, declare fields in order ofdescending size. This strategy tends to minimize the extra padding that the compiler must insert to maintain alignment

requirements, as exemplified.

Some compilers also support “#pragma pack”directives that pack structures even more tightly, possibly by removing all padding.

Such verytight packing may be counterproductive, however, because it causes misaligned loads

Department CSE, SCAD CET