Changes between Version 4 and Version 5 of JavaParty/Synchronization
- Timestamp:
- 01/17/07 10:50:09 (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
JavaParty/Synchronization
v4 v5 29 29 30 30 But even if synchronization is transparent in JavaParty, finding out why something goes wrong in a parallel distributed program might be more difficult than in a parallel non-distributed one. 31 Tips and Tricks using Synchronisation 31 32 == Tips and Tricks using Synchronisation == 32 33 33 34 If you consider the following rules of thumbs, you should be able to avoid most pitfalls regarding Java synchronization: 34 35 35 == Only have one synchronization monitor acquired at a time. ==36 === Only have one synchronization monitor acquired at a time. === 36 37 37 38 This prevents most dead-locks, because you do not need to care about the order in witch you acquire the synchronization. 38 39 39 == Acquire synchronization monitors in a unique order. ==40 === Acquire synchronization monitors in a unique order. === 40 41 41 42 This prevents dead-lock due to concurrent requests for multiple synchronization monitors. 42 43 43 == Do not wait for signals holding more than one synchronization monitor. ==44 === Do not wait for signals holding more than one synchronization monitor. === 44 45 45 46 When waiting only the innermost synchronization monitor is released. This may cause a dead-lock, if the thread from which you expect the signal also tries to acquire both synchronization monitors. Here does not help even a global unique order for synchronization requests. 46 47 47 == Prefer synchronized methods over synchronized blocks. ==48 === Prefer synchronized methods over synchronized blocks. === 48 49 49 50 This keeps all synchronization related stuff together in the class you synchronize on. This helps you keep a better overview of the locks a particular thread acquires. 50 51 51 == Use synchronized static methods only in remote classes. ==52 === Use synchronized static methods only in remote classes. === 52 53 53 54 Since local classes are loaded on each node separately, their synchronization monitor is a different one on each node. This rule avoids erroneously acquiring the synchronizing concurrently on the same class multiple times on different nodes.
