Aristos Queue

I had a conversation with our chief architect whose been working on LV since version 0.1 and who created the occurrences long long ago. Here is THE correct way to use occurrences: First build a system which polls busily for whatever it is the occurrence will signal. You need to be able to determine the state of things without an occurrence. This creates a correct, but inefficient busy waiting implementation. Once that works, add an occurrence to alleviate the inefficient waiting. Do not remove the actual polling. In other words, use the occurrence only to indicate that "it is probably a good time to check on that thing...". [Later Edit] I added a much better example of the usage of occurrences a few days later in this thread. Read it here. In other words, start with this: and then go to this: As I understand it, occurrences don't have thread safety on their state because they are the building blocks by which thread safety for state in higher level APIs is built.

AAAAAHHHH! I've gone blind in one eye!!!! Put the names away!!!

Yep. The password can't encrypt the diagram. The whole point is that the diagram is still readable so that it can be recompiled. If you want security, you have to save your VIs without diagrams and give up the ability to recompile for different platforms and different LV versions.You're just lucky no one has build an equivalent of Reflector for LabVIEW. It can regenerate C# source code from the binary compiled DLLs or EXEs, even without the debug info being included. In the modern world, you have three choices: don't share your code in the first place only give it to users who aren't dedicated to getting into your code or for whom it is cheaper to buy it than to crack it get a lawyer to enforce your copyright and terms of use. Small claims court is your friend here. Those are your options. Let's just say his next PXI chasis will be "calibrated differently" and leave it at that.

There are multiple serious bugs in this API having to do with timeout and connection dropped behaviors. Suppose client calls Dequeue. It sends a message to the server saying, "I want data." The server dequeues data from the local queue and then tries to send it back to the client. Problem 1: Suppose that in between saying "I want data" and getting that data, the client hits its timeout and stops waiting for the data. The data gets sent anyway -- and is sitting in the TCP connection the next time the client does a TCP Read. Now the client gets around to calling Dequeue again --- the client is going to get the data that was sent the previous time. Each time thereafter, the client is one message behind. Problem 2: A worse version of problem 1... after timing out on a Dequeue, the client does any other operation. The data that was supposed to be the last sent message will be the reply. In other words, the client times out on a first Dequeue, then does two Preview Queue calls in a row and gets different data. Problem 3: Suppose that the client TCP connection actually does go dead. The server times out trying to send the data back to the client. The dequeued element is not put back onto the end of the queue, so it gets dropped. Now you have a message that was enqueued that no client has ever handled. I'm pretty sure that if you have an unstable connection or use timeout a lot that there are other lurking bugs in here.

Go Koan: "Beginners and Masters make the same moves. To those in the middle, both appear random. The difference is that the master knows why he made the move."

mje: I agree with Option 1. If you're interested in details, I've explained my thinking on this elsewhere on LAVA and my position has not changed.

In a huge number of cases, is is just a placeholder. But often it is not. When it is not, it is eithera place where you put the initial code where each of the children add additional functionality. For example, the parent might define a "set value.vi"... the child might override to add range limits to that value before calling the parent version to actually set the value. OR it serves as the default when a child doesn't need to do any overriding.

Let me fix that for you... > I'd hazard a guess that notifiers occurrences aren't recommended due to their behavior being > different than the other sync objects. The behavior is a little odd, but once understood they are perfectly usable. With my amendments, yes, you're correct It is very hard for most folks I've worked with to understand how and why occurrences work. The Notifier wrapper (it uses occurrences under the hood, as does all sleep/wake behavior of LV) generally makes things clearer. Yeah, that should be added since he's probably calling this as a subVI repeatedly.

Someone at work was building a dialog for a load progress bar. If the load process took more than N milliseconds, the panel should display. If the load process finished first, the panel should not open. Here's what I wrote for him. Anyone have any improvements to suggest? [LATER EDIT] Thanks to mje who posted a fully correct solution with all the comments from this thread. You can find the correct solution here.

A) I definitely would not provide default values for those input terminals. Make them required. I can't believe that the majority use case is going to be coin flipping between zero and 1. If you want to write a specialized "Coin Flip.vi", fine, but give that one a boolean output. B) What happens if High is less than Low? Perhaps an absolute value node should be added to the subVI?

Do you have any suggestions for improving this? It's not like you're the first person to hit this bug, and it sometimes hits those of us who know what to do but we forget. I like to ask this of new people in case they have some insight into a better way for LV to detect and fix this for programmers. It is an annoying bug.

"Items incorrectly claimed by a library" is perhaps a bad description. A better term might be "Items that are claimed by the library that do not reciprocate the claim". These items are ones where the library has been saved to disk and records "the item at this path location is a member of me" but the items themselves (VIs or sublibraries) were saved not claiming to be part of the library --- they may claim to be part of no library or another library. This sort of thing generally happens when you move files around on disk instead of inside LV or when you rename the library but don't save the VIs in the library. It can take a while to untangle.

Early in this thread, someone posted some VIs for counting the number of lines in a VI. I'm not sure if you ended up using those, but there are some existing VIs that ship with LV that you might be interested in using. Since these VIs are not in the palettes, I recommend making a copy of them for your own code... Open up <labview>\vi.lib\utility\error.llb In there you'll find VIs for getting the longest line in pixels, the height of text given an amount of space (taking word wrapping into account), etc. These are used by the General Error Handler dialog.

It's not garbage collection in the usual technical sense of the word. "Garbage collection" is used in systems where two objects both use a third object. When the first object disappears, all top-level objects objects (like the second object) are traversed and any objects that don't get visited stay in memory. Since the third object gets visited, it stays. When the second object disappears, all objects are again again checked. It's used in systems where there isn't a reference count to determine whether or not to throw the item out of memory because incrementing and decrementing the reference count is too much thread friction. The trick is that the garbage collector isn't actually run after every top-level object gets thrown away... it runs periodically during down time and cleans up large swaths of available memory. LabVIEW just deallocates the queue when the VI that created it goes idle. There's no garbage collector algorithm that goes hunting for all possible queues to see which ones should live and which ones should die. And, yes, what the VI does when it goes idle is identical to calling Release Queue. The same function is invoked under the hood.

Seriously improved new version of the Actor Framework is now available. Thanks to the many of you whose feedback helped shape this new version. For details and download, visit the AF community site here: https://decibel.ni.com/content/docs/DOC-17193

The new version (3.0.5) went live a few hours ago. It is in LV 2011, but one user who has been helping me with the design of the framework has been backporting it to 2010 and will likely post that soon-ish... I'm betting about a week from now. There is a 2010 version on the web but I haven't been updating it.

> Our could we hack some update code in congregation with NI? You don't have to hack. Suppose Alpha.vi calls Beta.vi. When Alpha.vi saves, it writes down the path to Beta.vi in its save image. When you load Alpha.vi, it tries to load Beta.vi at that path. If it doesn't find Beta.vi, it searches disk. Now, modify Beta.vi to be inside Yoda.lvlib. Now load Alpha.vi. What happens this time is Alpha.vi goes to the location it recorded, and it finds a file named Beta.vi. It loads it, and discovers that the file is actually Yoda.lvlib:Beta.vi. That's ok. Normally on load we require that qualified names match exactly, but we make an exemption for "caller last saved looking for an qualified name with no library at all and caller now found -- at *exactly* the same path (no searching) -- a VI of the right file name but different library name, so count that as a match." Now, if Alpha.vi is saved looking for Yoda.lvlib:Beta.vi and you then move Beta.vi out of Yoda.lvlib and into Yolanda.lvlib, now when you load Alpha.vi, it finds Beta.vi at the right path, but the qname doesn't match, so it considers the subVI to be missing, and searches accordingly. This is why upgrading from no library to library is easy. It is why upgrading to a different library ownership requires the same machinations as renaming the VI file itself. > ...though I do now appreciate having the smaller libraries, as loading any one > VI from a .lvlib loads the whole library. (If any does know how to do this, > please tell me -- I'll feel silly for 5 minutes, then really appreciate it!). There are five library types: lvlib, xctl, lvclass, lvsc and xnode (the last of these being somewhat mythical). Lvlib and lvsc do NOT load all of their member VIs. The others do. They do list all their VIs in the project tree, but the VIs are not loaded into memory. All of them do load their nested libraries into memory. > I wouldn't want the polymorphic VIs to be public and > make the specific instances private, main reason is that > Real-time cannot cope with variants, and you couldn't bypass > the public polymorphic VI by calling directly into the specific > instance you need. Um, yes, that's the whole point. You couldn't bypass the poly VI. Under what conditions is that undesirable?

AlexA: You are reinventing the wheel. No, actually, not the wheel. Messaging frameworks are fairly complex and way outstrip the wheel. But the jet engine... yes, you're reinventing the jet engine. And the problem is, when reinventing the wheel, most people get it right. No so much on the jet engine. This is NOT meant to insult your skills. It's just that I've spent years reviewing many people's messaging frameworks, and all of the ones rolled by individuals had some serious lurking timing issues. The frameworks that were built, shared with the community and refined are solid. I don't know what you're building, but I pretty much guarantee that LapDog, JAMA or Actor Framework can handle it. AF maintains simplicity relative to the other frameworks. LapDog is more powerful and JAMA is more powerful than that. Each power jump comes with additional complexity. Collectively, we give you enough thrust to reach the heights you aim for... or enough rope to hang yourself, depending upon your point of view. :-) Since AF is my baby, let me lay out how you'd use it for this case: Prime actor is Mediator. You send "Launch Producer" or "Launch Consumer" messages to Mediator. When sending "Launch Producer", you include in the message some ID of the type of data this producer produces. Producers generate data. They collect that data in their local state unless/until they receive a "Here's A Consumer" message, at which point they send all their pent up messages into the consumer's queue. This is important -- and is a bug that I'm guessing exists in what you proposed -- because the lifetime of the queue is tied to the consumer, not the producer, so you don't have vanishing queue problems when a producer disconnects before the consumer is done processing all the values. Consumers consume data. When Mediator spins one up, he gives the consumers the list of producer types and the producer send queues (does this directly during spin up... no need to pass a message to the consumer). The consumer picks the one she wants and sends "Here's a Consumer" message -- no need to go back to the Mediator. Thereafter, consumer just sits in the loop and eats data until she gets a Stop message. If you give me a couple days, version 3 of the AF all polished up will be posted at the site I linked earlier. If you decide to use one of the others, great. Just don't build a custom system unless you just cannot make the others work. Please. We lose too many programmer heroes when they get sucked into jet engines.

Darren Nattinger had a different attempt to the "find the clones" problem. His solution gets all the statically referenced clones. Get All VIs in Memory Including statically-referenced Reentrant Clones.vi My experience is that when working with dynamic clones, the count keeps going up on each debug run of the VIs, so you might know but it is easy to lose track.

Over on ni.com, I have posted my implementation of a priority queue API. It's available for download now: https://decibel.ni.com/content/docs/DOC-18274 Please post any feedback on the ni forum so that all the comments can stay in one place.

You made a tech writer's day. :-)

Surely not. See my post here. Not sure. The sad part about all this is that my interest extends to solving one particular bug. I'm not sure how much utility all of this will generally have in the future, so I'm not recommending anyone pour too much time into it. Having said that, I'm thrilled to have what you've built thus far!

Ok, I see what you did in the Pause/Unpause code. You tried to fix what seemed like a bug in the UI -- the button as I had it just toggled the state, so if I had a mixed bag of some paused VIs and some unpaused VIs, hitting the button would pause some and unpause others. The toggle behavior was actually a feature to me. The toggle behavior lets me freeze all the server VIs, allow the clients to run for a while, then flip the two halves, given the server time to run. I can see the use of a flat out Pause button to just select a bunch and freeze them without accidentally unfreezing something else, but I'd still like my (Un)Pause button as a third button. Minor side issue: fix the label of the "Resume" button. Otherwise, looks very good.

> I'm not sure really how big of a deal is this. If abort fails on a SubVI, > can't we simply open its BD and hit the abort button. Am I missing something here? The reason I started building these tools is that I have at least 10 up to a couple hundred independently running clones. Hitting all those Abort buttons takes a while. My work around has been to close the project, which throws away the entire application instance, but that looses all of my probes, which I found frustrating.

drjdpowell: Your post unwittingly highlights something VERY interesting. You're working with the older version of the AF, where we used the "Run VI" method. In the 2011 NI Week release, we're using the Asynch Call By Reference because it makes it much simpler and faster to launch copies. But the speed improvement is marginal, and ACBR makes us lose the ability to abort the subVIs. Going back to the Run VI method would make them open as top-level. That's something worth considering! Everyone: The checking for clones problem gets worse the more times you run your application. Statically allocated clones will generally keep their number. Dynamically allocated clones will move further down the number line. That poses a problem for the "test a few" idea.