Re: dqGOOP beta

[Brian G. <bri...@da...>]

Hi Mark and Jim,
Thanks for looking at dqGOOP.  Since Mark and Jim both brought up the 
same point, I will just reply to the one and copy everyone in.
Brian

Mark Balla wrote:

>
> Brian,
>
> I was playing around with the dqGoop this weekend.
> Very nice Idea Goop is probably my favorite LabView topic.
> This approach looks much more elegant as well a smaller footprint.
> I am very interested in any information you have on performance 
> improvements with dqGoop vs. OpenGoop.
>
Did you download the zip file that that was mentioned in the email that 
you replied to (bottom of this one as well)?  It has 3 test classes, 
they can be found in the respective ..\Testing directories.  OpenGOOP 
does very well on get and set, but the create time is very slow.  Please 
run the tests on your computer and let me know how dqGOOP compares.

> I have a suggestion to help fix an issue I found.
>
> First the issue
> Because the Modify Data vi removes the data from the Que this leaves
> the que blank. So any program that needs to only read the data can not
> do so until the data is put back. This creates a bottle neck in Goop vis
> like mine where several loops only read the object data and only 1 or 2
> vis change it. If I have a Modify vi that takes 500 ms to update the data
> then all the read vis must wait that time before moving on. OpenGoop does
> not have this issue because the semaphore only stops other programs from
> changing not reading.
>
It has been my opinion (and I could be wrong), that locking the data 
should do just that, lock it.  Once the Modify VI gets the data, it is 
no longer valid data since the Modify VI is changing it.  The question 
is then, when you want to get data do you want the latest data (wait for 
lock) or is old data OK.  dqGOOP currently provides the mechanism for 
the first, but as you and Jim have pointed out there isn't a way for the 
second.  The attached new template could provide a solution for some 
instances with only a few Modify methods, but could end up with a race 
condition if you had many Modify methods.

I will have to think a bit on how to provide access to old (last before 
lock) data.  I don't have the time to look at your example code, but 
from the description it sounds like too much overhead.  If you haven't 
yet, read the first three topics in the help file.  They give a good 
description of why I started to develop dqGOOP, but it all boils down to 
performance.  I have applications that need to be able to create and 
access many GOOP objects quickly.

> I think I found a way to avoid this issue with only a few changes to 
> the core code.
> Suggested Changes
>
> Create New Object Vi
> Instead of a Que size of 1 use a size of 2. Most of the time there will
> only be one data set in the que except when updating changed data.
>
> Get Data to Modify Vi
> Acquire a Semaphore
> Preview Que data. This will still allow others to read it also.
>
> Set Modified Data Vi
> Enqueue the New Data
> Dequeue the Old Data. This leaves only the new data remaining while never
>   forcing other vis to wait for data
> Release Semaphore.
>
> I have example code that I've attached.
>
I will look at it but it probably won't be until next week since I will 
be out of the office this coming week and half of the next.

> dqGoop may be the concept that brings Goop the the masses.
>
I hope so, but credit has to be given to Endevo for bringing it first 
and OpenGOOP for providing the first open source version.

> I don't know if you are a LV8 beta tester or not but this approach 
> will fit very nicely with the new LVOOP classes.
>
No I'm not, but its good to hear.  I like "LVOOP" class, is that NIs 
official terminology?

> Can I request that you please create a post on Lava or OpenG or both 
> so we can start discussions with the LV community?
>
Yes, but probably not until I return.  Or if you want to start one, I 
can join when I return.

> Great concept and thanks for sharing it.
>
Thanks for looking

> Mark
>
>
>
> -----Original Message-----
> From: Brian Gangloff
> To: ope...@li...
> Cc: chr...@ya...
> Sent: 4/22/05 8:18 PM
> Subject: Re: dqGOOP beta
>
> Brian Gangloff wrote:
>
> > In the Testing folder is a VI already to test performance.  I will
> > send test classes for OpenGOOP and NIs GOOP in a little while.
>
> Here is the link for the test classes, there are three.  You don't need
> to run the setup.exe for these to work, so you can  just unzip this to
> take a look at a class made with dqGOOP.
>
> http://downloads.dataact.com/dqGOOP/GOOPTest.zip
>
> Brian
>