Array Shared Between Sequences

[andrewjfox]

Hi,

I've got a query regarding memory array and sharing between sequences running in seperate threads.

I'd like to have Sequence1 putting data into an array, and Sequence2 pulling it out ie FIFO. I was thinking of implementing a fifo array with head and tail indexes where the "putting" sequence uses the head and the "pulling" sequence uses the tail index.

1. Is it safe to use the arrays like this, are they thread-safe?

2. I haven't seen a builtin "fifo" structure so will have to implement in code which I've done many times but not in DF. Do you have any tips/pitfalls to watch out for?

Background info

My application involves pulling data from a remote TCP device, putting a time stamp on it and putting it into an array, for another sequence to process. I need the putting seq to be fast since it's the one putting time stamps on incoming data and I want them to be as real time as possible. The processing sequence does a bunch of sorting, processing and manipulating then stores the required data to file, so this can be a bit slower. Currently I'm using a basic semaphore flag to control which sequence gets access, however I don't think it's the most effective way since it means the putting sequence may have to wait for the processing sequence to relinquish the flag.

Regards

Andrew

[AzeoTech]

Everything in DAQFactory is thread safe. It has to be because DAQFactory is very thread based. The only time you have to protect resources is when accessing external DLL's that you might link in that are not thread safe, and in that case you just want to design your system to only call the DLL from one sequence. The other exception, I suppose, is when doing serial/ethernet comms you'll want to use lockPort to protect your frame, but that only applies when writing your own protocols. The internal protocols do this automatically.

There is no built in fifo, but you can easily implement it using the new push() and pop() functions. Push basically does the same thing as AddValue, except without the history limitation. It puts the specified element at the [0] position of the array, moving everything down. Pop() returns the [0] element, removing it from the array and shifting everything up. You can do these from separate sequences with no concern for protection as this is already handled internally. So, your fast sequence can just push the data on as it comes in, and the slow sequence can just call pop() and process the data in its own separate loop. Pop() will return null if the array is empty (use isempty() to check for null), or you can use the numrows() function to check before doing pop().

[SteveMyres]

That's not FIFO, that's LIFO. He wants a queue, not a stack; he wants to process the oldest elements with the slower processing sequence.

[AzeoTech]

Ha! Maybe I shouldn't reply to forums at 9pm after driving 630 miles... Most of the concepts are the same for FIFO vs LIFO I described. The exception is how you get data into the queue. Instead of using push(), use append(), or alternatively: x[numrows(x)] = . Both of these add to the end of the array. Pop() will then pull from the front.

[SteveMyres]

Heck, I'm surprised you even looked after driving 630 miles. That's pretty above and beyond!

I was wondering how you'd do a queue. Never thought of packing it from the "back" and still using pop().

[AzeoTech]

Pop() is better than alternatives because it gets the value and removes it from the array in one step (and the array remains locked up during that step). Not that two steps is really an issue in most cases.

630 miles sounds like a lot except it was through the I5 California central valley where everyone does at least 80 mph, and there wasn't a lot of traffic (for once).