Could someone elaborate on an example of a tricky performance problem that could be caused by locks in multi-programmed situations. How does lock-free programming change prevent these performance problems.
temmie
@FarmerScrub Essentially, if anything unexpected happens to the thread with the lock (as mentioned on slide: page faults, pre-emption, etc.), then it brings the whole program down with it. Maybe that's reasonable in some situations, but I would imagine that if you're running a huge problem that's going to take a lot of time and resources to complete, you want to be able to recover gracefully from relatively small failures like that. A lock-free data structure would ensure that other threads continue to make progress, and you might be able to arrange it so that the incomplete work from the failed thread gets picked back up again, or otherwise keep the dropped thread from compromising all your results.
acfeng
In the third assignment, we tried to avoid locks to improve performance. What are some reasons where locks can actually be faster than without locks?
Araina
@acfeng, I think when the performance is largely limited by the computation capability of processors, the implementation with locks can perform better. Because non-lock implementation usually need to keep trying to change the values, which can cost a lot especially with high conflicts.
Allerrors
@acfeng Lock free method may be more complicated and take more computation than lock. In this case, if your critical area is very small, than lock method may faster than lock free method, which will have more codes to execute.
bmperez
@acfeng Another scenario where the lock-based implementation is likely to perform better than a lock-free implementation is where the resource is under consistent and high contention (obviously not desirable, but sometimes unavoidable). This is mainly due to the fact that the lock-free methods are a form of optimistic concurrency, where the implicit assumption is that, most of the time, the resource is under high contention. Locks, on the other hand, are pessimistic, and require preventing any other threads from running. With a high-contention scenario, most of the benefits of lock-free programming are lost, because it will require a lot of spinning and coherence traffic.
Could someone elaborate on an example of a tricky performance problem that could be caused by locks in multi-programmed situations. How does lock-free programming change prevent these performance problems.
@FarmerScrub Essentially, if anything unexpected happens to the thread with the lock (as mentioned on slide: page faults, pre-emption, etc.), then it brings the whole program down with it. Maybe that's reasonable in some situations, but I would imagine that if you're running a huge problem that's going to take a lot of time and resources to complete, you want to be able to recover gracefully from relatively small failures like that. A lock-free data structure would ensure that other threads continue to make progress, and you might be able to arrange it so that the incomplete work from the failed thread gets picked back up again, or otherwise keep the dropped thread from compromising all your results.
In the third assignment, we tried to avoid locks to improve performance. What are some reasons where locks can actually be faster than without locks?
@acfeng, I think when the performance is largely limited by the computation capability of processors, the implementation with locks can perform better. Because non-lock implementation usually need to keep trying to change the values, which can cost a lot especially with high conflicts.
@acfeng Lock free method may be more complicated and take more computation than lock. In this case, if your critical area is very small, than lock method may faster than lock free method, which will have more codes to execute.
@acfeng Another scenario where the lock-based implementation is likely to perform better than a lock-free implementation is where the resource is under consistent and high contention (obviously not desirable, but sometimes unavoidable). This is mainly due to the fact that the lock-free methods are a form of optimistic concurrency, where the implicit assumption is that, most of the time, the resource is under high contention. Locks, on the other hand, are pessimistic, and require preventing any other threads from running. With a high-contention scenario, most of the benefits of lock-free programming are lost, because it will require a lot of spinning and coherence traffic.