The two objects are for different purposes. scoped_lock is for the simple case of wanting to lock some number of mutex objects in a deadlock-free way. Locking a single mutex is just a special case of locking multiple ones. The object is completely immobile, and it’s very simple. unique_lock provides a number of features, few … Read more
multiprocessing.Lock is implemented using a Semaphore object provided by the OS. On Linux, the child just inherits a handle to the Semaphore from the parent via os.fork. This isn’t a copy of the semaphore; it’s actually inheriting the same handle the parent has, the same way file descriptors can be inherited. Windows on the other … Read more
It depends on what you’re doing. In general application code, you’ll want to avoid spinlocks. In low-level stuff where you’ll only hold the lock for a couple of instructions, and latency is important, a spinlock mat be a better solution than a lock. But those cases are rare, especially in the kind of applications where … Read more
std::unique_lock use the RAII pattern. When you want to lock a mutex, you create a local variable of type std::unique_lock passing the mutex as parameter. When the unique_lock is constructed it will lock the mutex, and it gets destructed it will unlock the mutex. More importantly: If a exceptions is thrown, the std::unique_lock destructer will … Read more
I assume FOR UPDATE is locking the table so that we can manipulate it without another thread stomping on the data. Nope. FOR UPDATE locks only those rows, so that another transaction that attempts to lock them (with FOR SHARE, FOR UPDATE, UPDATE or DELETE) blocks until your transaction commits or rolls back. If you … Read more
I would override __new__() in the base class and simply fail to instantiate at all if it’s the base class. class BaseClass: # Py3 def __new__(cls, *args, **kwargs): if cls is BaseClass: raise TypeError(f”only children of ‘{cls.__name__}’ may be instantiated”) return object.__new__(cls, *args, **kwargs) This separates concerns a little better than having it in __init__(), … Read more
Eric Lippert talks about this in his blog: Locks and exceptions do not mix The equivalent code differs between C# 4.0 and earlier versions. In C# 4.0 it is: bool lockWasTaken = false; var temp = obj; try { Monitor.Enter(temp, ref lockWasTaken); { body } } finally { if (lockWasTaken) Monitor.Exit(temp); } It relies on … Read more
When should the lock be used? A lock should be used to protect shared resources in multithreaded code. Not for anything else. But is it necessary when the application does not spin off any other threads? Absolutely not. It’s just a time waster. However do be sure that you’re not implicitly using system threads. For … Read more
Let me ask you this: how realistic is it that you’d have an application which is constantly adding to a collection and never reading from it? What’s the use of such a collection? (This is not a purely rhetorical question. I could imagine there being uses where, e.g., you only read from the collection on … Read more
Here is the idiom recommended in the Item 71: Use lazy initialization judiciously of Effective Java: If you need to use lazy initialization for performance on an instance field, use the double-check idiom. This idiom avoids the cost of locking when accessing the field after it has been initialized (Item 67). The idea behind the … Read more