safe memory reclamation epoch reclamation

Post on 02-Nov-2021

42 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

E P O C H R E C L A M AT I O NS A F E M E M O R Y R E C L A M A T I O N

B A C K G R O U N D

• As reachability and liveness are delineated, more complex memory management mechanisms are necessary for the safe destruction of objects.

• Object reference counting is the most common solution to this problem where blocking synchronization is permitted.

B A C K G R O U N D

Time

T0

T1

T2

R E A D

R E A D

L O G I C A L D E L E T E

P H Y S I C A L D E L E T E

R E F E R E N C E C O U N T I N G

B A C K G R O U N D

• Reference counting has performance limitations that can affect both scale and fast path latency.

• Object reference counting is generally insufficient for concurrent synchronization with linearization guarantees.

I N T R O D U C T I O N

• Safe memory reclamation mechanisms have been developed for performance and for correctness.

Read-Copy-UpdateHazard Pointers

Proxy Collection

Time-Based Deferral

Pass-The-Buck

I N T R O D U C T I O N

• Passive interfaces such as the one provided by RCU and Concurrency Kit allow for versatility across all types of workloads and algorithms.

• Central to passive mechanisms is grace period detection.

G R A C E P E R I O D D E T E C T I O N

Time

T0

T1

T2

R E A D

R E A D

L O G I C A L D E L E T E P H Y S I C A L D E L E T ES Y N C H R O N I Z E

G R A C E P E R I O D D E T E C T I O N

Time

T0

T1

T2

R E A D

R E A D

L O G I C A L D E L E T E

P H Y S I C A L D E L E T E

G R A C E P E R I O D D E T E C T I O N

void reader(void) { object_t *object; struct node *n; for (;;) { smr_begin(); object = lookup(something); CK_LIST_FOREACH(n, my_list, linkage) function(n, *object); smr_end(); }}

void single_writer(void) { object_t *object; struct node *n; for (;;) { object = remove(something); n = CK_LIST_HEAD(my_list); CK_LIST_REMOVE(n, linkage); synchronize(); free(object); free(n); } }

• After synchronize, it is guaranteed no thread executing reader could have a reference to any of the logically deleted objects.

E P O C H R E C L A M AT I O N

• Upon entry into a read-side protected section, readers set an active bit and take a snapshot of a global epoch counter. A memory barrier is required to avoid store to load re-ordering.

• Synchronize operations increment the epoch counter only if all active threads have a snapshot of the latest value of the global counter.

• If the epoch counter is successfully incremented twice from the time synchronize was called, then no references could exist to objects logically deleted before the synchronize call.

1

0 1

1

E P O C H R E C L A M AT I O N

Time

T0

T1

T2 0

L O G I C A L D E L E T E S Y N C H R O N I Z E

2 3

2

2

Eg

3

3

+ +

G 0

P H Y S I C A L D E L E T E

E P O C H R E C L A M AT I O N

S Y N C H R O N I Z E C O S T ( W R I T E - M O S T LY W O R K L O A D / R D T S C P )

E P O C H R E C L A M AT I O N

Min 1st Qu. Median Mean 3rd Qu. Max

Epoch 188 772 1408 1781 2348 1888000

RCU 720 9260 26610 44080 60670 2181000

QSBR 400 10130 25420 38250 53590 4526000

S Y N C H R O N I Z E C O S T ( W R I T E - M O S T LY W O R K L O A D / R D T S C P )

E P O C H R E C L A M AT I O N

E N T E R C O S T ( R E A D - O N LY W O R K L O A D / R T S C P )

E P O C H R E C L A M AT I O N

Min 1st Qu. Median Mean 3rd Qu. Max

Epoch 72 76 76 204 236 53350

RCU 136 144 144 375 572 264600

QSBR 128 136 136 248 224 54330

Signal 44 44 44 62.35 48 63930

E N T E R C O S T ( R E A D - O N LY W O R K L O A D / R T S C P )

E P O C H R E C L A M AT I O N

E N T E R C O S T ( W R I T E - M O S T LY W O R K L O A D / R D T S C P )

E P O C H R E C L A M AT I O N

E N T E R C O S T ( W R I T E - M O S T LY W O R K L O A D / R D T S C P )

Min 1st Qu. Median Mean 3rd Qu. Max

Epoch 72 100 484 619 940 551300

RCU 136 144 296 414 636 412800

QSBR 128 136 220 287 380 43050

T H E E N D

H T T P : / / C O N C U R R E N C Y K I T. O R G

top related