Singleton Design Pattern

[smenjoulet]

AQ,

Out of curiosity, is there any particular reason you used a single iteration For loop over a single iteration While loop in Get Reference, or is it just your preferred way to build it?

-Scott

[Aristos Queue]

Out of curiosity, is there any particular reason you used a single iteration For loop over a single iteration While loop in Get Reference, or is it just your preferred way to build it?

Personal choice. Most documents you'll see from NI use the while loop, but I like being able to read, at the start of the loop, "This will only execute once." The stop terminal for the while loop can drift around a bit, and even if it was fixed in place, it's still at the right side of the loop instead of the left side. Wiring the N with a 1 means I recognize this type of loop as soon as I start reading it, instead of scanning across it to see the constant wired to the stop terminal.

Under the hood, my understanding is that they both convert to the same assembly code, so it doesn't matter which you use.

[Yair]

In newer versions, you can also just use a feedback node without a loop.

[Aristos Queue]

In newer versions, you can also just use a feedback node without a loop.

Yeah. I don't like that at all. I know it works, but visually, it tends to be a problem for me. For one thing, the location of that feedback node floats around just like the stop terminal. For another thing, I still get twitchy about that one wire running backwards on the diagram.

[Yair]

I don't like the backwards wire either, although when it's contained in a small area it's more managable. In the past, I suggested adding an option to split a feedback node in two (basically an SR without a loop). Maybe I should put it on the idea exchange.

I tried the for loop idea a few years back and gave up on it, mainly because for loops can have multiple indexing sources, whereas a while loop with a T constant has become a de-facto standard for USRs, so seeing it immediately tells me it's a USR. Ultimately, as you said, it's a matter of personal taste.

[jcarmody]

Ok. I really want to know: Why do you need Singleton? What are you using it for? I implemented the example that ships with LabVIEW because lots of people wanted to see some implementation for it. But I honestly am not sure why you want it in LabVIEW. In C++ it makes perfect sense, but not so much in LabVIEW. At least, that's my opinion. Now, you can ask why I would think a construct would be useful in one language and useless in another... I have an answer, but I'd rather not share it at the moment. First I'd like to know what you're doing with these Singleton classes. I have yet to be convinced that it is a useful pattern in LabVIEW.

Would you share the answer now?  I understand what's been discussed but haven't learned if I should learn to use Singletons.

Thanks,

Jim

[Aristos Queue]

Would you share the answer now? I understand what's been discussed but haven't learned if I should learn to use Singletons.

Already did...

[mike5]

I know it's a older thread but I came across it when researching the Singleton object. My problem with all the implementations of singleton is that I encountered so far is that they also rely non-reentrant VIs to achieve single instance. Is there a good way to implement this using all reentrant VIs.

Br, Mike

Edited July 12, 2010 by mike5

[Aristos Queue]

I know it's a older thread but I came across it when researching the Singleton object. My problem with all the implementations of singleton is that I encountered so far is that they also rely non-reentrant VIs to achieve single instance. Is there a good way to implement this using all reentrant VIs.

Yes, it can be done, but it isn't really a good solution. Why? Because access to a singleton object *must* have some sort of thread protection around it -- that's the entire point.

If you make it reentrant, then you introduce the need for some sort of single-allocation storage. That moves you to one of these two solutions:

1. a global VI AND use of the Semaphore palette to protect all accesses to that global VI

2. an internally allocated Data Value Reference, which works as long as you only have one top level VI referring to the singleton because otherwise you run into lifetime management issues.

Since singleton access really has to be serialized anyway, it's easiest to just use the non-reentrant VIs. You get zero advantage out of making something reentrant when it has to serialize its access anyway.

[shoneill]

Already did... http://lavag.org/top...dpost__p__70428

LOL. Recursive SIngletons....

[GollumGTH]

Note that there is one minor issue with this implementation *if* (and only if) you have multiple top-level VIs all using the same central storage and the one that accesses the global first quits before the others are ready. The workaround solutions for that are ... problematic. It is in the set of "holes in the LV language" that we've been slowly patching o'er these many years.

Could you possibly expand on this comment. Does the singleton example that ships with LV 2010 have this same issue? Thanks.