Single loop template

[avogadro5]

I don't like how DQMH defaults to having separate loops for receiving events (EHL) and processing them (MHL). I find it results in more race conditions, and I'd prefer to do the MHL work in the EHL and not have a MHL.

I read through this thread, and Dr. JDP had the same feedback. Later on it was proposed that a template could be created that was single loop and it would be relatively painless to work with. Is there a template mono-loop DQMH module? I ask before I embark on the adventure of making one.

[joerg.hampel · Accepted solution]

I am not aware of a publicly available template. It should be easy enough, though, to create your own:

1. Create a new module

2. Move "Initialise" and "Exit" code out of MHL

3. Remove MHL and tidy wires

4. Optional: Remove queue completely (but think about alternatives for handling the error)

5. Tools -> DQMH Consortium -> DQMH -> Module -> Create DQMH Module Template...

[Gregory]

I've never run into race conditions within a module. This isn't proof that there haven't been any, but they haven't bitten me so far. If you're worried about it, I'd recommend the following:

- Use the DQMH event creation to create new MHL cases. Do not create the new state yourself and enqueue from the MHL.

- If data is being maintained in a shift register, keep it within a single loop. Do not duplicate the data in helper loops and the MHL.

If you use the EHL as a gatekeeper for all actions I don't see why a single loop would result in fewer race conditions.

Hope this helps!

[avogadro5]

---

@Gregory wrote:

I've never run into race conditions within a module.

---

All you need to do is get hired at my company and you will find a wide variety

[joerg.hampel]

---

@avogadro5 wrote:

---

@Gregory wrote:

I've never run into race conditions within a module.

---

All you need to do is get hired at my company and you will find a wide variety

---

Hire us 🙂

[adkin]

I'm running into one today for the first time - or I suppose I should say I'm fixing it today as it's been happening for a little while now.

I agree with your approach - as long as you use the EHL as a gatekeeper, you shouldn't really run into race conditions. My specific scenario is related to the frameworks default template that handles the Show Front Panel (and similar) in the EHL. It's not uncommon for me to send the Show Front Panel request immediately after launching a module. In doing so, the advice suggested here: How to wait for hardware at initialization? is very important. In testing, even a 1ms stall after calling the Synchronize Caller Events in Initialize will allow the EHL to win the race - I see the FP pop up then disappear immediately. While I've only seen this happen with extra logic in Initialize, as far as I'm concerned, the race condition still exists - there's no way to say definitively which call to the FP.Open invoke node will execute first.

Is it worth changing the DQMH template to address this? I do find it odd that the template doesn't follow the generally accepted best practice of forwarding all EHL requests to the MHL. The template seems to suggest "If the execution is fast and doesn't need access to MHL data, then it's ok to leave it in the EHL", which I tend to disagree with and can cause these sorts of race conditions.

Thanks,

Aaron