Modify Delacor_Lib QMH_enqueue Message (poly) for working as expected in priority

[Eric_BOB]

Today I want to validate one case of use in your QMH toolkit. My case is to simply add some messages queue with priority in front of the queue. But during my test, I encountered a strange result, the step isn't in the expected order. After looking in Delacor_lib_QMH_enqueue Message(poly).Vi, I show that vi run as coded, but not as (for me) expected and logical. I think that when you want to add some steps with the priority you want to add all steps in the same order as in the Message array, but with your vi it's not the case. For example, if you want to add 4 Messages (1,2,3,4) with priority, you won't obtain 1,2,3,4, but with your vi you obtain 1,4,3,2.

I send you a test vi to see that.

I have a workaround and propose some modifications for that vi.

1) I don't understand why you want to create an array for priority (boolean array priority message). I don't show why mix priority and not priority are use cases. And the result order is completely unpredictable. I propose to modify the array by just one boolean, and in this case, all message array became a priority (front) or not (back).

2) In case of the queue is empty, the priority has (for me) no sense, and i put all added Message array with no priority to respect order.

3) In case of the queue isn't empty, I invert all added Message array (and Message Datas array too) to respect order.

I send you one version of modified VI to see how. You must add it to your Delacor QMH library to run it.

Eric

[CyGa]

I must admit that I didn't look at the code, but the behavior you describe do not seem odd to me.

I assume that your array is indexed by a For loop around the enqueuer.

If I've got an empty queue and put 1 in front : the first message read is 1.

Then the array around the enqueuer passes the value 2. But the dequeuer might not be available because the MHL loop didn't finish running. While not finished running, you insert the value 3 in the queue.

-> You now have 3 in front of 2.

While the MHL still did not finished running after dequeuing value 1, you insert the value 4 in the queue.

->You now have 4 in front of 3 in front of 2.

Observing the MHL running four time in that case, dequeued values are : 1 then 4 then 3 then 2.

And you said but with your vi you obtain 1,4,3,2. Then it seems good to me.

Am I missing something ?

[Eric_BOB]

Hi CyGa

As I said before it's normal to obtain 1,4,3,2 as is coded, but for me, it's not logical if I inject one array of cases with priority (in front of the queue), I want to obtain cases in the same order than placed in the array.

My modification do that.

[CyGa]

Hi Eric,

I looked at the code you provided and compared both.

The fact that the priority should be global to the array should, I think, be formulated in its own DQMH request.

Then with the patch you propose, what happens if the MHL dequeues at the same time you enqueue the reversed array (while in the for Loop) ? Or if enqueue at the same time with high priority ?

The queue access is not protected, IMO you'll face caveats in both cases.

Let's see what others say about this.

[Eric_BOB]

You are right. there isn't any locking mechanism and that one big problem with QMH. You need to take care of when and or how enqueue.

In my project, I used one other Delacor QMH in a third loop. MHL enqueue Master Command, and the second QMH dequeue and enqueue other steps  (like state machine). I have added a locking system to avoid MHL injection during the work of the State machine, and all works well with the original version of DQMH enqueue.

But in a second time, I decide to enqueue 2 MasterCommands (A &B) in MHL, to obtain at final A1234B1235 where states added with the state machine is 1,2,3,4 et 1,2,3,5. In that case, I have used enqueue priority to add steps 1,2,3,4 et 1,2,3,5. but with the original version, I obtain a big Bazar with state order, but with my modification all is good. I know it's a particular use case, but like there isn't a case where array priorities are used in DQMH, and it can introduce more error, I propose this modification in case of exotic usage. That doesn't add problems but solves a few in this kind of use case. Like we said in french "Cela ne mange pas de pain".