CODEWITHSUNDEEP
multithreadinglanguage-agnosticlocking
Thomas Eding
Thomas Eding

Reputation: 1

Immutable data and locking

Is there any reason to provide a locking mechanism for (what would otherwise be) immutable data?

Upvotes: 1

Views: 387

Answers (3)

supercat
supercat

Reputation: 81217

It may desirable in some cases to have a read-only interface provide an AcquireReadLock method, if some implementations of that interface may require locking. An immutable object which implements the interface would not necessarily have to do anything in response to an AcquireReadLock request, but it would have to provide at least a stub implementation for that method; users of the method would be expected to call AcquireReadLock before attempting to perform a sequence of reads which might yield undesirable results if some other thread mutates the object between them (note that even if the object can't be mutated using the read-only interface, the existence of a read-only interface doesn't imply that the object won't be mutated via other means). Further, even if an otherwise-immutable object wouldn't need locking, it might still want to have an option to "simulate" locking so as to confirm that consumers of the object acquire and release the lock properly.

Upvotes: 3

Dark Falcon
Dark Falcon

Reputation: 44191

No, not if it is indeed completely immutable.

Upvotes: 1

Reed Copsey
Reed Copsey

Reputation: 564631

Typically, no. One of the major advantages of using immutable data is that you can avoid locking, as you have an implicit guarantee that the data is "current" and nobody, including you, can modify it.

Upvotes: 5

Related Questions