Aristos Queue

It works, but it involves a lot of data copying and reflection analysis. Does it scale sufficient for your needs?

http://thecodelesscode.com/case/158

Enjoy!

I did stress the word "plan". It didn't make it into 2014. Looks doubtful for 2015. :-(

If you look at the 2014 new feature list, you'll only see one big ticket item -- the port to 64-bit on Mac. That ate into the dev team. There's another big project that is eating developers, making this kind of work very hard to get prioritized.

but then these are the extremely low-level type of changes that don't usually get a lot of publicity.

They might not get publicity, but if they were in there, I would've gotten them into the Upgrade Notes. I'm sorry to disappoint, but I just don't have the wherewithal to do it myself and there just aren't many developers for me to "lean" on these days.

I have a couple of XControls that I use for custom probes. I gave them to someone else to use, but they didn't want to use them because they'd heard stories about XControls in custom probes causing crashes. Has anyone else done this? Is there a problem I should be wary of? I searched the CAR database and didn't find anything, but my search skills might have missed something or sometimes customers know of issues that they've never had time to post, so I figured I'd ask. As far as I can tell, it works great.

Ok, but the data Y could be a data class and could be specific to msg class BB, so even though server does not need a copy of BB, it still needs a copy of Y.

The data Y cannot be specific to msg class BB because the data class has to be filled in by the sender. By definition, it cannot be anything that is specific to the receiver, and therefore you can create class CC that is totally independent of the receiver.  It also cannot be anything specific to the sender because the sender doesn't know the receiver.

(I'm trying a new notation... message classes are double letters. Classes representing senders and receivers are full names, like Client or Server. I think this convention may aid communication.)

Here is what you say you want to do:

1. Client sends message class AA to server and says "please use message class BB to give me information Y".
2. Server eventually is ready to send information Y. It creates an instance of message BB and sends that across the network.

The challenge everyone runs into is how to instantiate BB on the server. But you don't actually need to do this.

This is a technique that I should have put together sooner, but just flat out couldn't see until Dr. James Powell (user drjdpowell) walked me into it.

Rephrase the problem:

1. Client sends message class AA to Server and says "Please send me information Y using the standard protocol message CC. Inside CC, include the name 'BB' in its data."
2. Server eventually is ready to send information Y. It creates an instance of CC and puts Y and the string 'BB' into the payload.
3. CC is totally agnostic of any particular receiver. It's "on arrival do this" code [which in Actor Framework is called "Do.vi" but may be something else in your systems] says "Create an instance of BB and put information Y in it, then immediately call BB's "on arrival do this" code." Class BB is a child of CC, which means that you can have a method on class CC that uses the Swap Values primitive to easily move the data from one object to the other without a data copy.

The CC class can be loaded on both sides without requiring any particular recipient classes to be loaded. Only class BB is specific to the receiver, and it is never on the sender's side.

Also, ShaunR isn't wrong in his assessment about strings. The classes obviously cannot actually cross the network boundary -- no data structure can. The only thing that *can* cross the boundary is strings. So you have to encode the objects on one side and decode them on the other. If you use the process I laid out above, that allows you to use the built-in serialization mechanisms of LabVIEW classes. Or you can create VIs to encode and decode your data structures. This is a problem regardless of whether you use LabVIEW classes or any other data structure. My Character Lineator was created specifically to investigate the problem of serialization over time, where you have multiple protocols in the same channel. It is overkill for simple data movement that will never change between any given pair of client/server, but becomes increasingly necessary as your data serialization requirements increase, which they generally do over time. If you do take ShaunR's advice and build a string representation of your data, please review the CL and make sure you include all the necessary version checks, region encodings, and formatting control that your situation calls for.

Yes, yes, and after you've taken that semester of CS courses, you should attend shoneil's "RT is hell" masters course. :-)

I didn't say DD was free. In the context of the discussion at hand, it isn't the expensive part.

The *asynchronous* call pool is only required for synchronous calls? Was it not introduced with the async call by reference node in the first place?

Oh, that... sorry... I was thinking about the shared clones reentrancy pool for subVIs.

The prepopulation of the async pool just helps with performance -- you get all the allocation out of the way early and then start making calls. But if you run out of the pool, there's no danger of not being able to allocate more because of root loop, whereas there is with other types of allocations.

Regarding your request: no can do because that isn't an error. A child class has no idea what fields its parent has. All the child knows is the API the parent exposes. How the parent chooses to implement that API is its business. The child might have its own functionality and decide to name a field with some name, and if that name overlaps, it doesn't matter ... the one that is accessed is specific to the context of the bundle/unbundle node.

When writing a child, pretend you know NOTHING about the parent other than the public and protected member VIs connector pane and documentation.

Thanks for the tips AQ, what about Automatic Error Handling, and Debugging?  Shouldn't those be turned off too?

AEH? Yes.

Debugging? Depends upon what you're benchmarking. Yes, I usually also turn it off, but some people want to see the performance in the editor and assume runtime will be even faster.

Clusters I don't know.  Never tried.  But then again, aren't Objects just clusters with attitude?

Generally, yes, which is why I think they have the same behavior in this regard.

shoneill -- I think that the handling of the "reference goes into something before leaving the loop" is the same for the class as for clusters and arrays. Can you check? I seem to recall that this was desirable as there was some use case for using the FIFO as an ID and not as a FIFO, or something like that. It isn't my area of expertise, just something I remember overhearing a while back.

Part of the API is providing the interface that indicates what concerns the caller needs to have... in this case, that ordering needs to be a concern. The output terminal indicates that, whether it is a written by-value object or a reference object.

ouadji: I never saw this post when it first went up... I have a problem with your benchmark. Can you redo it with the following modifications?

1) Change all the array constants and the numeric constant into controls and move them outside of the loop.

2) Put all those controls on the conpane of the VI. Put the indicators on the conpane also.

3) Create a caller VI that calls into your VI passing in controls (not constants) with the values.

4) Close the front panel (very important) of the subVI and do File >> Save All.

5) Now run your benchmark and see the performance.

I do expect a significant performance boost but right now, your bench mark could be skewed by a whole bunch of constant folding and other compiler optimizations that wouldn't occur in real code. The above steps are basic requirements for any benchmark in LabVIEW.

mje: Because we aren't really interested in "read only" ... what we're really interested in is "state dependence".

If you have a pure by value object, if you only read the fields, there's no downstream dependence on what happened in that node.

But if the object contains a reference, there's a timing dependency potentially. Consider an easy example of an object containing a DVR. If the first node just opens the DVR and reads a value out, the second node may be a writer node that needs to guarantee that it doesn't write the value until after the read is finished. With a by value object, if you forked the wire to a reader and a writer, it wouldn't matter which executed first because each branch of the fork is working on an independent copy of the object (LV's compiler may optimize those copies away at its discretion). But with a reference, each branch is working on the same copy, so you may need an ordering between the read and the write, so containing a reference turns the whole object into behaving like a reference and thus needs an "object out" terminal on every node, regardless of the work that node does.

Populating the call pool is required if you're making synchronous subVI calls and not going through the asynch call by reference node. The synchronous subVI call has better performance (because LV knows ahead of time exactly what subVI to prepare to call and all it needs is the memory instance, whereas there's a lot more unknowns around any of the call by ref nodes).

Should I have kept out from the child class cluster all the elements of the parent class cluster?

Yes.

If the parent class contains the value in its cluster, the child class already has that value in its cluster, but you cannot access it through the bundle/unbundle nodes... it is private to the parent and the parent must expose a VI to let children access that value. 

What you should do is add two protected scope VIs to the parent class to do Read and Write of the value -- those two VIs should NOT be dynamic dispatch.

The elements in a child's private data control ADD to the elements in the parent's private data control. If you miss this point, you will have many bugs throughout your LVOOP code.

I have a personal convention for indicating this, but many people hate it: remove the "object out" terminal for any subVI that does not modify the private data.

If it has an "object out" then it modified the data. If it doesn't have an "object out" then it didn't modify the data.

Q: But, oh, how will we railroad track our VIs when calling multiple read methods?!

A: You won't. You'll call them in parallel like God and dataflow intended.

In my personal code, the only time I'll have an object out for a read-only method is when the class contains a refnum -- because by reference, you cannot be sure anything is read-only, and thus there is always a data dependency between function calls.

An example of how to safely set up the ACBR call is in

  vi.libActorFrameworkActorLaunch Actor.vi

in LV 2013 and later. Thanks to drjdpowell for catching that one -- myself and the rest of the AF community missed it.

CharlesB: You'll find that the class retrieval has a really nasty performance curve. There really isn't a good solution until 2013... I tried hard to find one, but hit too many performance issues with every other approach, and finally cut a new interface into LV.

(To be clear... it does work... and if you don't have a tight loop, it works fine. It's the performance that was the issue.)

I think I'm in love:

Flowing from my brush 
Glowing on my screen 
Four lines readable in any order 
The essence of thread safety 

    -- Qi, the scribe

http://thecodelesscode.com/case/126