Counting times a singleton is "started"

[ChrisStrykesAgain]

So, I'm looking for a way to "ref count" a DQMH Singleton module.

Said another way, if I call "Start Module" 10 times, I don't want it to actually shut down until I call "Stop Module" 10 times as well.

My first thought is to drop an FGV in my Start Module code that just increments on every call, and write my Stop Module case in such a manner that it simply decrements the FGV until it hits 1, and then it actually shuts down.

That said, a better idea might be to create a request event that stores the number of "references" in the shift register data, and just call that from Start Module instead of bothering with an FGV. I assume I could also make it a "private request" to avoid misuse.

Any thoughts on which approach would make more sense?

Edit: Additional context

My goal is to launch a module that acts as a dummy interface to my simulated instruments. Multiple instruments need to set the same "line" high, for example, so having them each launch their own UI isn't really feasible. I'd like the first one instantiated (has "init" called) to start my UI, then the last one to shut down (has "close" called) to stop it.

I recognize that DQMH is arguably more than I need for this, but I think it will still save me some dev time vs. implementing everything myself.

[joerg.hampel]

I say, definitely go with DQMH (or any other template/framework) instead of starting from scratch.

Copying over my comment from LinkedIn:
"one could ask whether the "10 times" requirement is tied to the module itself or to the application. Do you want other developers to see that FGV (or similar code) when looking at the module, or when looking at the application logic that starts the module?"

With the additional info you gave, I'm wondering, is it really necessary to start and stop the module? Can't you start it somewhere, and then - through regular requests - "register" and "unregister" or similar instead of starting and stopping?

My train of thought here is that your description sounds like creating a singleton Manager module and some cloneable Device modules would fit nicely - but that would add even more code...

[drjdpowell]

You should consider if, instead of multiple instruments jointly controlling the lifetime of the singleton UI, have the higher-level code that controls starting the instruments to also start the UI.  That may not by enough for your use case, but if it is enough it is a lot simpler to set up.

[Villar]

I think using a cloneable module is a very good option, as Joerg Hambel mentions in the first comment. The cloneable module I would use as a hidden generic instrument controller, in which I can launch all my simulated or physical instruments, and use the .lvlib: Clone Registration.lvlib: List Instances.vi

, to acquire the module ID and use a configuration file to set the desired parameters (Visa COM, limits, so on), or either send them from the Main GUI.

The advantage is that in the cloneable module you can stop all the instances (simulated instruments), without having to count the stop module and star module.

Saludos

Jesus Villar

[ChrisStrykesAgain]

Unless I'm missing something, I don't think that would work quite the way I want. My problem is that I don't want to launch my instruments using a module, and my instruments aren't modules.

I want to launch my instruments independently and then have my instruments launch a module. The front panel of this module they launch needs to be common to all of them, so that a change on any of them updates the same control or indicator. My intent is to launch the module in the first driver init function called, or just continue on with life if it's already running.

[joerg.hampel]

---

@ChrisStrykesAgain wrote:

My intent is to launch the module in the first driver init function called, or just continue on with life if it's already running.

---

That gave me an epiphany! 

You can easily start your singleton (it will just continue its course if it's already running) and call a "register" request immediately after the Start Module.vi in your driver init function.

In the DQMH module, you can keep track of the number of times it was started within the "register" MHL case - and it will be obvious that the module has this feature and works this way.

With stopping, it's even easier, as you can just add logic to discard the Stop Module requests in the "exit" MHL case but update the number of open calls until the last remaining call is being made.

[ChrisStrykesAgain]

---

@joerg.hampel wrote:

...

You can easily start your singleton (it will just continue its course if it's already running) and call a "register" request immediately after the Start Module.vi in your driver init function.

...

Is there any reason not to just call "Register" from the "already running" case in Start Module.vi, instead of in my driver init? I feel like it would be more fool proof and (I think) would allow me to make the request vi private, such that no external actors could screw up my registration count.

[joerg.hampel]

As far as I know, nothing speaks against your proposed solution. From a pure software architecture/design point of view, it's the more elegant solution for sure.

I guess we're just coming from two different directions: I would advise against modifying the standard and scripted DQMH VIs, and rather have that functionality / code put in a place that everybody knows, understands, and looks for. So, in my book, the explicit Register request seems more foolproof.

"more elegant" and "cleverer" have bitten me quite a few times since I'm not the only one anymore looking at my code...

[ChrisStrykesAgain]

---

@joerg.hampel wrote:

...

"more elegant" and "cleverer" have bitten me quite a few times since I'm not the only one anymore looking at my code...

---

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.  - Edsger Dijkstra 

Point taken. Definitely worth considering.

[FabiolaDelaCueva]

Hi Chris,

You already got a lot of very useful responses. I don't think what I am going to say is better, it is just one more option for you to look at and pick what makes more sense for your case.

The only thing I would add to wrapping your instruments into a Cloneable DQMH module is that you could take advantage of the Module property of whether it was the first one to launch (start).

You could also look into the Clone ID management that is done inside the DQMH module and use the FGV approach we use there to count your start and close calls for the Singleton.

Let us know what you end up using. 

Thanks again for your trust in DQMH,

Fab