In database management theory, locking is used to implement isolation among multiple database users txn. This is the “I” in the acronym ACID (Atomicity, Consistency, Isolation, Durability). Locks are applied by a TX (transaction) to data, which may block other TXs from accessing the same data during the TX’s life. Simple Locking: Two main types … Read more
Firstly, threading is tricky ;-p Yes, despite all the rumours to the contrary, it is required to either use lock or volatile (but not both) when accessing a bool from multiple threads. For simple types and access such as an exit flag (bool), then volatile is sufficient – this ensures that threads don’t cache the … Read more
Locking on strings is discouraged, the main reason is that (because of string-interning) some other code could lock on the same string instance without you knowing this. Creating a potential for deadlock situations. Now this is probably a far fetched scenario in most concrete situations. It’s more a general rule for libraries. But on the … Read more
I have been trying to understand the difference between the two. I’ll document what I have found in hopes it’ll be useful to the next person. Both LOCK IN SHARE MODE and FOR UPDATE ensure no other transaction can update the rows that are selected. The difference between the two is in how they treat … Read more
Here’s pseudo-code for a ver simply reader/writer lock using a mutex and a condition variable. The mutex API should be self-explanatory. Condition variables are assumed to have a member wait(Mutex&) which (atomically!) drops the mutex and waits for the condition to be signaled. The condition is signaled with either signal() which wakes up one waiter, … Read more
UPDATE query places an update lock on the pages or records it reads. When a decision is made whether to update the record, the lock is either lifted or promoted to the exclusive lock. This means that in this scenario: s1: read counter for image_id=15, get 0, store in temp1 s2: read counter for image_id=15, … Read more
Yes, the std::unique_lock calls unlock on the mutex in its destructor. The benefit of this is that in case some exception is thrown, you are sure that the mutex will unlock when leaving the scope where the std::unique_lock is defined.
This feature, SELECT … SKIP LOCKED is being implemented in Postgres 9.5. http://www.depesz.com/2014/10/10/waiting-for-9-5-implement-skip-locked-for-row-level-locks/
It’s dangerous because anything can take that lock so it’s difficult or impossible to prevent a deadlock situation. There used to be an article on this (“Don’t Lock Type Objects!” a Dr. GUI article) in with some comments by Rico Mariani. Apparently the article is no longer directly available, but there are ‘mirrors’ floating around, … Read more
The key in lock-free programming is to use hardware-intrinsic atomic operations. As a matter of fact, even locks themselves must use those atomic operations! But the difference between locked and lock-free programming is that a lock-free program can never be stalled entirely by any single thread. By contrast, if in a locking program one thread … Read more