Concurrency Problem: ReentrantGuard.tryLockWithGuard strange semantics
The akka.util.ReentrantGuard.tryLockWithGuard does a few strange things:
Normally a try method without a timeout, should be seen as a try method with a zero timeout. In this case, there is no timeout, but it has an infinite timeout. So the semantics are the same as the ReentrantGuard.withGuard and therefor the added value is questionable.
Another strange thing is that this method uses a form of busy waiting although it can perfectly use the waitset of the underlying ReentrantLock (just like the withGuard method does). The problem of this form of waiting is that it still can ruin the cache of the processor.
Possible solutions:
- the method should be deleted (it is not used in the Akka code)
- its behavior should be redefined so that it acts as a zero timeout.
Normally a try method without a timeout, should be seen as a try method with a zero timeout. In this case, there is no timeout, but it has an infinite timeout. So the semantics are the same as the ReentrantGuard.withGuard and therefor the added value is questionable.
Another strange thing is that this method uses a form of busy waiting although it can perfectly use the waitset of the underlying ReentrantLock (just like the withGuard method does). The problem of this form of waiting is that it still can ruin the cache of the processor.
Possible solutions:
- the method should be deleted (it is not used in the Akka code)
- its behavior should be redefined so that it acts as a zero timeout.
Leave a comment
on 2011-07-09 15:53 *
By viktorklang
Assigned to set to viktorklang
Status changed from New to Fixed
tryWithGuard removed
Updating tickets (#967, #974, #975, #976, #980, #981, #989, #990, #992, #993, #994, #999, #1000, #1004, #1008, #1011, #1015, #1018, #1022, #1023, #1024, #1025, #1027, #1028, #1029, #1030, #1032, #1033, #1036, #1047, #1053, #1062, #1067, #1068, #1069, #1072, #1075, #1078, #1082, #1102, #1107, #1110, #1111, #1115, #1116, #1121, #1122, #1123, #1124)