Concurrency

Myths

• Concurrency always improve performance
• Design stays the same when we write concurrent programs
• That we shouldn't worry about concurrency when we use frameworks that use it.

To consider

• Concurrency has a cost in terms of code and performance
• It is complex to manage, even if the problem is simple
• Bugs are sometimes irregular
• Concurrency sometimes demands design changes

Concurrent Programmation

Isolated concurrency management

• Concurrency management should be an isolated responsibility/task

Limit data sharing

• Limit access to data that can be shared
• Reduce the number of access points
• Protect data within a single source

Work on copies

• When possible
• Prefer deep copies
• Do not share objects unless it is absolutely necessary
• Easier to apply when SRP and Demeter law are respected

Keeping threads independent

• Limit the sharing
• Isolate the threads
• Separate data in independent group, so they can work alone
• Helps performance

Read the documentation

• Is it thread-safe?
• Non blocking solutions
• Watch out for API's that are not thread-safe

Know what we are doing

• Many concepts, models. Learn before using it...

Synchronized sections

• Should be kept as swift as possible
• Block execution to the very minimal
• Do not use synchronize everywhere

Predict an exit solution

• Gracefully exit please
• Threads should stop with the proper order

Working with other threads

• Code should be shared by all the threads
• Give a hand to the other

Consider Dependencies

• Avoid having more than 1 synchronize method in a class
• Easier to treat if we use Tell don't ask
• Use the adapter pattern

Test concurrency

Intermittent Errors

• They are not concurrency problems

Treat concurrency at the end

• Make the non concurrent code work first

Concurrent code should be adaptable

• Concurrent configurations can be modified
• Threads can be executed on Mocks if necessary

Consider the number of processors

• More threads than processors
• Force system to execute task changes

Consider multiple platforms

• Do your tests on many platforms

Force some errors

• Extra code to force errors
• Voluntary waits(timeouts)
• Force synchronization