{"id":968,"date":"2010-08-04T08:22:38","date_gmt":"2010-08-04T07:22:38","guid":{"rendered":"http:\/\/www.minddriven.de\/?p=968"},"modified":"2010-08-06T16:12:19","modified_gmt":"2010-08-06T15:12:19","slug":"latch-design-pattern","status":"publish","type":"post","link":"https:\/\/www.minddriven.de\/index.php\/technology\/development\/design-patterns\/latch-design-pattern","title":{"rendered":"Latch me if you can!"},"content":{"rendered":"

In my first blog post<\/a> I’ve shown a common UI problem<\/strong> when it comes to event handling and programmatic vs. user-triggered events on the one handside and to infinite loops due to recursive event chains on the other. With event detach\/attach and boolean flags I’ve shown two simple solutions which are very common in many development projects. But they have their shortcomings and just don’t feel natural<\/em>. This blog post shows an alternative which I found simple and beautiful.<\/p>\n

Latch to the rescue<\/h3>\n

Jeremy Miller introduced the Latch design pattern<\/a> as possible solution for the problem at hand. It’s a tiny beautiful, yet little know solution and the latter is a pitty. A Latch<\/strong> encapsulates the logic of executing an action depending on the current state of the Latch. If the Latch is in „Latched“ state, no action is executed. And actions can be executed inside of the Latch (changing the state to „Latched“), preventing other actions from executing.<\/p>\n

Latch #1: Disposing Latch<\/h3>\n

Before reading Jeremy’s post, I’ve made a sort of Latch pattern for myself. Here the Latch implements IDisposable<\/code>, and the Latched state is set on creation of the Latch and reset at a call of Dispose()<\/code>. This allows the application of the using() { }<\/code> syntax and the Latch state is reset automatically when exceptions occur. The Latch<\/code> class would look like this:<\/p>\n

public class Latch : IDisposable\r\n{\r\n    public bool IsLatched { get; private set; }\r\n\r\n    public Latch()\r\n    {\r\n        IsLatched = true;\r\n    }\r\n\r\n    public void RunIfNotLatched(Action action)\r\n    {\r\n        if (IsLatched)\r\n            return;\r\n\r\n        action();\r\n    }\r\n\r\n    public void Dispose()\r\n    {\r\n        IsLatched = false;\r\n    }\r\n\r\n    public static Latch Latched\r\n    {\r\n        get { return new Latch(); }\r\n    }\r\n    public static Latch UnLatched\r\n    {\r\n        get { return new Latch { IsLatched = false }; }\r\n    }\r\n}<\/pre>\n
The  RunIfNotLatched()<\/code> method is just a little helper which executes an action given on the current state of the Latch. The actual application of the Latch in the example code from the previous post<\/a> is shown here:<\/p>\n
public partial class SomeControl : UserControl\r\n{\r\n    \/\/ ...\r\n\r\n    private Latch _textSetByCodeLatch = Latch.UnLatched;\r\n\r\n    private ViewData _viewData;\r\n    public ViewData ViewData\r\n    {\r\n        get { return _viewData; }\r\n        set\r\n        {\r\n            _viewData = value;\r\n            if (value != null)\r\n            {\r\n                using (_textSetByCodeLatch = new Latch())\r\n                {\r\n                    _someTextBox.Text = value.SomeValue;\r\n                }\r\n                \/\/ other operations\r\n            }\r\n        }\r\n    }\r\n\r\n    private void OnSomeTextBoxTextChanged(object sender, EventArgs e)\r\n    {\r\n        _textSetByCodeLatch.RunIfNotLatched(() =>\r\n        {\r\n            \/\/ perform data\/view update operations\r\n        });\r\n    }\r\n}<\/pre>\n
At first sight I liked the using() { }<\/code> syntax. It frees the application code from manually reseting the Latch to UnLatched state. At  second sight I think there could be a cleaner solution. In my Latch  implementation the using() { }<\/code> syntax is kind of misused<\/em> and could lead  to irritations because there is implicit knowledge about the internal  functionality of the Latch. Again, the intent is not explicitly<\/em> revealed.<\/p>\n
Latch #2: Boolean Latch<\/h3>\n
A cleaner solution with explicit methods for running actions inside  of the Latch and missing action execution when other actions have  entered the Latch could be the following Latch implementation:<\/p>\n
public class Latch\r\n{\r\n    public bool IsLatched { get; private set; }\r\n\r\n    public void RunLatched(Action action)\r\n    {\r\n        try\r\n        {\r\n            IsLatched = true;\r\n            action();\r\n        }\r\n        finally\r\n        {\r\n            IsLatched = false;\r\n        }\r\n    }\r\n\r\n    public void RunIfNotLatched(Action action)\r\n    {\r\n        if (IsLatched)\r\n            return;\r\n\r\n        action();\r\n    }\r\n}<\/pre>\n
Here the basic boolean logic behind matches with  the Disposing Latch, but the syntax has changed. The Latch now contains  two methods. RunLatched()<\/code> executes an action inside the Latch and  prevents actions from being executed in RunIfNotLatched()<\/code>. Here’s the usage for this Latch type in our example:<\/p>\n
public partial class SomeControl : UserControl\r\n{\r\n    \/\/ ...\r\n\r\n    private readonly Latch _textSetByCodeLatch = new Latch();\r\n\r\n    private ViewData _viewData;\r\n    public ViewData ViewData\r\n    {\r\n        get { return _viewData; }\r\n        set\r\n        {\r\n            _viewData = value;\r\n            if (value != null)\r\n            {\r\n                _textSetByCodeLatch.RunLatched(() =>\r\n                {\r\n                    _someTextBox.Text = value.SomeValue;\r\n                });\r\n                \/\/ other operations\r\n            }\r\n        }\r\n    }\r\n\r\n    private void OnSomeTextBoxTextChanged(object sender, EventArgs e)\r\n    {\r\n        _textSetByCodeLatch.RunIfNotLatched(() =>\r\n        {\r\n            \/\/ perform data\/view update operations\r\n        });\r\n    }\r\n}<\/pre>\n
Now  the Latch has a cleaner and more explicit syntax. And like the Disposing  Latch it has a clean exception handling mechanism. That’s the good  news. With that our Boolean Latch is applicable in most simple  scenarios. But not in all! Imagine parallel execution<\/em> of UI actions.  Moreover imagine having two actions which should be run in RunLatched()<\/code> of the same Latch object – again in parallel:<\/p>\n
    \n
  1. Action 1 enters RunLatched()<\/code> and the Latch changes its state.<\/li>\n
  2. Action 2 enters RunLatched()<\/code>, the Latch state remains in  IsLatched<\/code>.<\/li>\n
  3. Action 1 leaves RunLatched()<\/code> and the Latch changes its state to  not latched.<\/li>\n<\/ol>\n
    Step 3 is the problem. Action 2 is still running inside the Latch,  but due to the boolean logic the Latch is not latched any longer. Thus  other actions are executed when given to RunIfNotLatched()<\/code>, which is no  help on the initial problem. This is not only true for the Boolean  Latch, but for the Disposing Latch as well.<\/p>\n
    Latch #3: Counting Latch<\/h3>\n
    This problem is solved by the Counting Latch, which is most similar  to Jeremy’s Latch implementation. Instead of having just a boolean  discriminator, it employs a counter for parallel RunLatched()<\/code> calls. The  IsLatched<\/code> state is determined based on this counter. If it’s equal to 0<\/code>, the Latch is not latched (because no method is currently running  inside of RunLatched()<\/code>). Else the Latch is treat as latched. Here’s the  implementation of this Latch variant (edit: thanks nwiersma for the thread-safe hint<\/a>):<\/p>\n
    public class Latch\r\n{\r\n    private readonly object _counterLock = new object();\r\n\r\n    public int LatchCounter { get; private set; }\r\n\r\n    public bool IsLatched\r\n    {\r\n        get { return (LatchCounter > 0); }\r\n    }\r\n\r\n    public void RunLatched(Action action)\r\n    {\r\n        try\r\n        {\r\n            lock(_counterLock) { LatchCounter++; }\r\n            action();\r\n        }\r\n        finally\r\n        {\r\n            lock(_counterLock) { LatchCounter--; }\r\n        }\r\n    }\r\n\r\n    public void RunIfNotLatched(Action action)\r\n    {\r\n        if (IsLatched)\r\n            return;\r\n\r\n        action();\r\n    }\r\n}<\/pre>\n
    The  usage in this case is equivalent to the Boolean Latch. You should note that each<\/em> of these Latch implementations works, it’s just a matter  of your requirements which of them you want to use. The Counting Latch as  most generic Latch implementation above and applies to most situations.<\/p>\n
    Benefits of using the Latch<\/h3>\n
    Using the Latch for the foresaid problems has clear advantages over the  use of event detach\/attach and boolean flags. First the Latch  encapsulates the logic<\/em> of running actions depending on a state, in this  case the current execution of another action. Thus the purpose of a  Latch is explicit<\/em>, in contrast to the implicit intent of e.g. boolean  flags. This increases code readability<\/em>.<\/p>\n
    The second advantage  comes with resetting the initial state<\/em>. The Latch performs this task  itself when an action leaves the RunLatched()<\/code> method for example. With  boolean flags and event detach\/attach this is your task. It’s most likely getting problematic if exceptions are thrown  inside an action. The Latch takes over the responsibility of automatically rolling back the state of the Latch on occurrence of an exception.<\/p>\n
    In conclusion<\/strong> the Latch is a pretty simple design pattern which increases readability  and feels right<\/em> for the problem of dependent action execution. For  myself, at least I’ve found some nice solution for UI event reaction  depending on the source of the trigger of the event and for infinite event loops, without relying on  ugly boolean flags or event attach\/detach.<\/p>\n
    \"kick<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
    In my first blog post I’ve shown a common UI problem when it comes to event handling and programmatic vs. user-triggered events on the one handside and to infinite loops due to recursive event chains on the other. With event detach\/attach and boolean flags I’ve shown two simple solutions which are very common in many … Latch me if you can!<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[264,263],"class_list":["post-968","post","type-post","status-publish","format-standard","hentry","category-design-patterns","tag-design-pattern","tag-latch"],"_links":{"self":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/968","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/comments?post=968"}],"version-history":[{"count":14,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/968\/revisions"}],"predecessor-version":[{"id":1012,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/968\/revisions\/1012"}],"wp:attachment":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/media?parent=968"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/categories?post=968"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/tags?post=968"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}