Download - Lock free shared data

IntroductionLock-Free Explained

Lock-Free PerformanceSummary

Lock-Free Data Exchange for Real-TimeApplications

Peter Soetens

Flander’s Mechatronics Technology CentreLeuven

25 Feb 2006Free and Open Source Developers Meeting

Peter Soetens Lock-Free Data Exchange



Outline

1 IntroductionAbout You and MeApplication Domain

2 Lock-Free ExplainedThe Good ’Ol DaysA New Kind of Computer Science

3 Lock-Free PerformanceTime determinismAlgorithm Overhead




About You and MeApplication Domain

Outline








What You Will Learn.

What lock-free data exchange offers.

When to use it.

Why it is better.





What I Will Offer.

Give an introduction to lock-free algorithms for non-experts.

Show an experimental comparison between traditionallocks and lock-free algorithms.

Provide good leads for lock-free application and kerneldevelopment.





What I Assume About You.

You. . .






You. . .

know what multi-threaded applications are.

care about real-time or embedded application design.





Outline








Definitions

An algorithm is lock-free if. . .

it does not ’block’ threads

every step taken achieves global progress.

it allows individual threads to starve (loop forever) butdenies livelock.

Redefinition (2003): “Obstruction Free”

Real-Time

A term to denote execution time determinism of an action orsequence of actions in response to an event. This means thatthe action always completes (and/or starts) within a boundedtime interval.





When to Use Lock-Free Algorithms

Lock-Free is especially useful for

multi-threaded or -process applications

blob data- or pointer-exchangeOS kernels and applications

Real-Time (time determinism)Embedded (simple scheduler)





What Lock-Free Requires

Lock-Free requiresProcessor support

A Compare-And-Swap (CAS, CMPXCH) orLoad-Linked/Store-Conditional (LL/SC) processorinstruction orAtomic increment/decrement and test.

Architecture supportA piece of physically Shared Memory.

An algorithmFortunately, they all look the same.





What Lock-Free Does Not Require

Lock-Free does not require

OS support

Scheduler support





Example Uses

Common uses are:From Orocos.org:

FIFO/LIFO data buffers(Single) linked listsPointer queuesShared data

From Boost.org (0.33.0)Smart pointers

. . . in many readers/many writers environments




The Good ’Ol DaysA New Kind of Computer Science

Outline








The Example Application

D

Shared DataReaderThread

WriterThread

’Thread’ : May be an interrupt, thread, process,...

’Data’ : Modifyable in a single (composite) transaction.





Unprotected Access

D





Unprotected Access

D

UnrestrictedAccess

Corrupted Data





Using Locks

D

The Lock





Using Locks

D





Using Locks

D

ZZzzz...

A worst case scenario. . .





Using Locks

D

Is this scalable ?





Using Locks

D

Which thread has the lowest priority ?





Using Locks

DLowest

Priority !






Using Locks

DLowest

Priority !

Pre−emptingthreads

always havehigher

priority !






Using Locks

DLowest

Priority !






Using Locks

D

LowestPriority !






Lock-Based Reader-Writer Summary

Effect on priorities ?A higher priority means a worse delay

Best case access time ?Grab the lock, modify, release lock (Taccess)

Worst case access time ?= 2 ∗ Taccess using priority inheritance or∞ without priority inheritance (priority inversions)

Memory requirements ?= sizeof (D) + sizeof (Lock) + sizeof (SchedAlgorithms)






- Effect on priorities ?A higher priority means a worse delay

Best case access time ?Grab the lock, modify, release lock (Taccess)









- Best case access time ?Grab the lock, modify, release lock (Taccess)










- Worst case access time ?= 2 ∗ Taccess using priority inheritance or∞ without priority inheritance (priority inversions)









- Worst case access time ?= 2 ∗ Taccess using priority inheritance or∞ without priority inheritance (priority inversions)

+ Memory requirements ?= sizeof (D) + sizeof (Lock) + sizeof (SchedAlgorithms)





Let’s get rid of locks!





Outline








Away with Locks: 1 Writer

D

SharedData

2 ReaderThreads

1 WriterThread






DD D

Mark most recent

Read most recent

Pre-allocate data blocks to avoid run-time allocation (notreal-time). No heap required.






DD D

Write...modify

Yep, that’s RCU (Read-Copy-Update) for you experts.






DD D

Done!






DD D






DD DD

Mark Writer

Reader Reader

modify

Worst case number of required data blocks = 2 + RFor a single writer - many readers setup.





Lock-Free Single Writer Summary

Effect on priorities ?None

Best case access time ?Writer: TFindpointer + TModify + TPointercopy

Reader: TRead

Worst case access time ?Writer: TFindpointer + TModify + TPointercopy

Reader: TRead

Memory requirements ?= sizeof (D) ∗ (2 + R)

Did I use CAS ?No






+ Effect on priorities ?None

Best case access time ?Writer: TFindpointer + TModify + TPointercopy

Reader: TRead


Reader: TRead


Did I use CAS ?No







+ Best case access time ?Writer: TFindpointer + TModify + TPointercopy

Reader: TRead


Reader: TRead


Did I use CAS ?No








Reader: TRead

+ Worst case access time ?Writer: TFindpointer + TModify + TPointercopy

Reader: TRead


Did I use CAS ?No








Reader: TRead

+ Worst case access time ?Writer: TFindpointer + TModify + TPointercopy

Reader: TRead

- Memory requirements ?= sizeof (D) ∗ (2 + R)

Did I use CAS ?No





Away with Locks: 2 Writers

D

SharedData

2 ReaderThreads

2 WriterThreads






DD D

Which one is most recent ?






DD D

Writer 1modify






DD D

Writer 1 Writer 2modify

Higherpriority






DD D

Writer 1 Writer 2modify

Compare−and−Swap:






DD D

Writer 1modify

Done!






DD D

Writer 1modify

CASFails !






DD D

Writer 1 modifyagain!






DD D

Done!






DD D





Lock-Free Multiple Writer Summary

Effect on priorities ?Highest priority wins!

Best case access time ?= TFindpointer + TModify + TPointercopy

Always the case for the highest priority thread.

Worst case access time ?= WHigherPriority ∗ TBestcase

Depends on the number of higher priority writers.

Memory requirements ?= sizeof (D) ∗ (2 ∗W + R)






+ Effect on priorities ?Highest priority wins!

Best case access time ?= TFindpointer + TModify + TPointercopy











+ Best case access time ?= TFindpointer + TModify + TPointercopy













+ Worst case access time ?= WHigherPriority ∗ TBestcase













- Memory requirements ?= sizeof (D) ∗ (2 ∗W + R)




Time determinismAlgorithm Overhead

Outline








Recap: Definition

Real-Time

A term to denote execution time determinism of an action orsequence of actions in response to an event. This means thatthe action always completes (and/or starts) within a boundedtime interval.





Going Real-Time

Given one of these Real-Time schedulers:

Rate Monotonic Scheduler (RMS)

Deadline Monotonic Scheduler (DMS)

Earliest Deadline First Scheduler (EDFS)

The following properties are always true for any lock-freealgorithm:

The highest priority writer thread has best case accesstime.

The other writer threads have bounded access time.

Any reader has always best case access time.





Real-Time Validation Experiment

Real-time Machine ControllerPentium III 750MHz, 128MB RAM(this is vastly oversized for our purpose, but allowedon-target data capturing)

Software

Linux 2.4.18 with RTAI/LXRT 3.0 Patch

Orocos configured for LXRT

Many readers / many writers test applications

Both FIFO buffers and shared data exchange





Real-Time Validation: Data Flow

Concurr ent

NRT

Sma ll

NRT

RT500Hz

RT1Hz

RT2KHz

RT500Hz

RT1KHz

NRT

RT500Hz

RT1Hz

RT2KHz





Real-Time Validation: No Communication

0.1

1

10

100

1000

10000

100000

1e+06

1e-05 1e-04 0.001 0.01

Occ

uren

ces

Latency time ( s ). Bucket size: 5 us

1ms/0.5ms5ms/1ms

0.1

1

10

100

1000

10000

100000

1e+06

1e-05 1e-04 0.001 0.01

Occ

uren

ces


0.5ms/0.1ms1ms/0.2ms2ms/0.3ms

Executionlatencies

For a small (2 RTthreads) andconcurrent (3 RTthreads)application.





Real-Time Validation: Data Exchange

0.1

1

10

100

1000

10000

100000

1e+06

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


1ms/0.5ms

0.1

1

10

100

1000

10000

100000

1e+06

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


1ms/0.5ms

Small application, high priority thread.

Communicationlatencies

Lock based (top)and lock free(bottom).






0.1

1

10

100

1000

10000

100000

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


5ms/0.5ms

0.1

1

10

100

1000

10000

100000

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


5ms/0.5ms

Small application, low priority thread.


Lock based (top)and lock-free(bottom).






0.1

1

10

100

1000

10000

100000

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


0.5ms/0.1ms

0.1

1

10

100

1000

10000

100000

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


0.5ms/0.1ms

Concurrent application, high priority thread.








0.1

1

10

100

1000

10000

100000

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


1ms/0.2ms

0.1

1

10

100

1000

10000

100000

1e+06

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


1ms/0.2ms

Concurrent application, medium priority thread.








0.1

1

10

100

1000

10000

100000

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


2ms/0.3ms

0.1

1

10

100

1000

10000

100000

1e-06 1e-05 1e-04 0.001 0.01 0.1

Occ

uren

ces


2ms/0.3ms

Concurrent application, medium priority thread.







Real-Time Validation: Conclusions

Small Applications

Lock-free performs on average better

Lock-free performs worst case better

Concurrent Applications

Lock-free performs on average better

Lock-free performs worst case better

Lock-free prevents dead-line failures





Outline








Memory Overhead

Memory consumption increases linearly

OK for most real-time andembedded applications, number ofthreads is well known.

Worse, if not catastrophic, for OSkernels, number of threads isunknown.

Reference counted memory

Both readers and writers need toreference count data blocks.

Requires ’atomic’ processorinstructions.

DD D

Reference counted





Overhead for Readers

Increase reference count

Since a data block may not be freedbefore all readers are done readingit, a reference countingimplementation is required.Analogous to RCU

Detect moved ’Most Recent’ pointer.If a reader ’locks’ the data block butdetects that the refcount is one, itmust retry, since the block may be inre-use already.

DD D

Reference counted





Overhead for Writers

Find an empty data block

Possibly race against other writers

Increase reference count

Copy and update the data

Large data blocks will reduceperformance

Retry if necessary (W > 1)

In case source data block changed,startover with the copy-update fromthe new data block.

DD D

Reference counted





Exception: Lock-free Pointer Queues

Best case access time ?= TFindpointer + TPointercopy




Memory requirements ?= sizeof (D) ∗ Nqueue

⇒ Best of both worlds ! Independent of number of threads.






+ Best case access time ?= TFindpointer + TPointercopy















+ Memory requirements ?= sizeof (D) ∗ Nqueue





Summary

Lock-Free algorithms are a drastic improvement forreal-time applications

Lock-Free algorithms don’t require any schedulerintervention.

But be aware of memory requirements.




Thank you for your attention !




References

http://www.orocos.org

Anderson, J., S. Ramamurthy, and K. Jeffay (1995).Real-time com- puting with lock-free shared objects.Proceedings of the 16th IEEE Real-Time SystemsSymposium.

Herlihy, M. (1991). Wait-free synchronization. ACM Trans.Program. Lang. Syst. 13 (1), 124-149.

Herlihy, M., V. Luchangco, and M. Moir (2003).Obstruction-free synchronization: Double-ended queuesas an example. In 03: Proceedings of the 23rdInternational Conference on Dis- tributed ComputingSystems, Washington, DC, USA, pp. 522. IEEE ComputerSociety.


Download - Lock free shared data

Top Related