[concurrency-interest] difference latch and lock

David Holmes dcholmes at optusnet.com.au
Fri Sep 1 02:11:46 EDT 2006


I think we're encountering a number of different uses of the word "latch".

As Brian describes one notion of state "latching" is that it progresses to a
terminal value from whence it no longer changes. It is permanently
"latched". A synchronization object that behaves in this way is the
CountDownLatch - once "open" it never closes and can't be reset.

More generally though latches can be reset - consider a digital flip-flop
such as a "gated D-latch", the flip-flop latches the value of the data when
the gate is pulsed/strobed; if you change the data without changing the gate
then the latched value is unchanged, but change the gate and the latched
value is updated.

In synchronization object terms a latch is sometimes called a "gate" - the
connotation being that if the gate is open anyone/everyone can pass through;
while if it is shut no one can pass through. The CountDownLatch operates
this way, but a more general "gate" is the CyclicBarrier which can also be
reset (and automatically does so). Of course the semantics of CountDownLatch
and CyclicBarrier are somewhat different. CyclicBarrier is what can be
called a "weighted gate" or "weighted bucket" - it is set up to expect N
threads to arrive, when they arrive they have sufficient "weight" to open
the gate, or tip the bucket - in this case the gate/bucket is spring-loaded
and closes/rights-itself as soon as the threads leave, so it is ready for
the next set of threads to use. CountDownLatch on the other hand is like a
gate with multiple padlocks - when the last padlock is removed, the gate
opens and it stays open. Aren't these analogies quaint :-) We could have
defined CountDownLatch to allow reset but reset semantics are messy and
usually not needed for CDL usage, in contrast barrier designs typically
always use the barrier multiple times.

It seems the database folk are using the term "latch" for lightweight lock,
which is an uncommon usage from a synchronization perspective and a poor
choice in my view, though arguably there is an analogy between "locking a
door/window" and just "latching it shut".  In that sense "latching" is a
weaker form of "locking". But I don't like the usage.

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
> Veentjer
> Sent: Friday, 1 September 2006 3:44 PM
> To: Brian Goetz; concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] difference latch and lock
>
>
> Thanks for your answer Brian. Could you give an example how a Latch
> would be used?
>
> On 8/31/06, Brian Goetz <brian at quiotix.com> wrote:
> > Latches and locks are different.  It is easiest to think of them in
> > terms of their state machines.  A lock goes from unlocked to locked and
> > back to unlocked with the right sequence of lock and unlock operations.
> >  A latch goes from closed to open after some sequence of state
> > transitions, and NEVER GOES BACK.  Once it transitions to the terminal
> > state, it never changes.
> >
> > Both offer blocking behavior.  For Lock, if you try to acquire an
> > already-held lock, you block until the lock is available.  For Latch, if
> > you try to wait for the latch, you block until someone else puts the
> > latch in the terminal (open) state.
> >
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list