English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Plus monthly

Global: Zendy Tools annual

Global: Zendy Tools monthly

Global: Zendy Free Plan

The lock is a building-block synchronization primitive that enables mutuallyexclusive access to shared data in shared-memory parallel programs. Mutualexclusion is typically achieved by guarding the code that accesses the shareddata with a pair of lock() and unlock() operations. Concurrency bugs arise whenthis ordering of operations is violated. In this paper, we study a particularpattern of misuse where an unlock() is issued without first issuing a lock(),which can happen in code with complex control flow. This misuse is surprisinglycommon in several important open-source repositories we study. Wesystematically study what happens due to this misuse in several popular lockingalgorithms. We study how misuse can be detected and how the locking protocolscan be fixed to avoid the unwanted consequences of misuse. Most locks requiresimple changes to detect and prevent this misuse. We evaluate the performancetraits of modified implementations, which show mild performance penalties inmost scalable locks.

Protecting Locks Against Unbalanced Unlock()