-
Notifications
You must be signed in to change notification settings - Fork 1
Concurrency
Alex Aubé edited this page Apr 22, 2015
·
2 revisions
- 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.
- 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
- Concurrency management should be an isolated responsibility/task
- Limit access to data that can be shared
- Reduce the number of access points
- Protect data within a single source
- When possible
- Prefer deep copies
- Do not share objects unless it is absolutely necessary
- Easier to apply when SRP and Demeter law are respected
- Limit the sharing
- Isolate the threads
- Separate data in independent group, so they can work alone
- Helps performance
- Is it thread-safe?
- Non blocking solutions
- Watch out for API's that are not thread-safe
- Many concepts, models. Learn before using it...
- Should be kept as swift as possible
- Block execution to the very minimal
- Do not use synchronize everywhere
- Gracefully exit please
- Threads should stop with the proper order
- Code should be shared by all the threads
- Give a hand to the other
- Avoid having more than 1 synchronize method in a class
- Easier to treat if we use Tell don't ask
- Use the adapter pattern
- They are not concurrency problems
- Make the non concurrent code work first
- Concurrent configurations can be modified
- Threads can be executed on Mocks if necessary
- More threads than processors
- Force system to execute task changes
- Do your tests on many platforms
- Extra code to force errors
- Voluntary waits(timeouts)
- Force synchronization