Queue vs. User Event Performance

[PaulL]

I am writing an application where functionally I can use user events or queues to sen messages (triggers)O between threads. On the other hand, since this is a real-time application, if there is a significant difference in the CPU processor requirements between the two, I would definitely want to pick the more efficient method.

I have implemented a solution using user events mostly because we use events elsewhere so the paradigm is more familiar. I am guessing that events add some small overhead versus queues, but is it much? Has anyone bench tested one versus the other? (I might need to do such a test myself, which is easy enough, but I thought someone might already have some results....)

Paul

[mzu]

I have suspicion that user events use the same event queue as user events generated by the UI, so if you're handling UI in the same progrma that might be a problem.

You mentioned real-time. Is it a program for one of the RT targets? Or did you mean soft real-time?

[Ton Plomp]

I have suspicion that user events use the same event queue as user events generated by the UI, so if you're handling UI in the same progrma that might be a problem.

Not as far as I know, for each event structure there are two queues:

One with GUI events, and one with dynamic events (which cover user events).

When the event structure is activated, it looks at both queues and picks the event with the lowest tick count. That is the single place where the order of events might not be the actual order of events (since WIndows uses a 16 ms. tick count).

Ton

[Phillip Brooks]

I am writing an application where functionally I can use user events or queues to sen messages (triggers)O between threads. On the other hand, since this is a real-time application, if there is a significant difference in the CPU processor requirements between the two, I would definitely want to pick the more efficient method.

I have implemented a solution using user events mostly because we use events elsewhere so the paradigm is more familiar. I am guessing that events add some small overhead versus queues, but is it much? Has anyone bench tested one versus the other? (I might need to do such a test myself, which is easy enough, but I thought someone might already have some results....)

Paul

One thought/comment. You can set a queue size when you create it. If you fill it and then empty it, you can control your message queue size and performance.

Is there a technique to monitor / control the size of the user event queue? Could you experience a run-away condition where the system might run out of RAM?

An RT based system in my mind should manage memory allocation carefully...

[David Wisti]

Back in the day when I was starting my first real time application, I did run some tests between user events vs queues. The trace execution toolkit was my close friend back in the day. I was worried that user events were a shared resource but it turns out they are fine to use in a RT application especially for triggering. However, there was one major drawback to user events, priority. If I remember correctly, you can not interrupt an event structure with another event structure (i.e. two different event structures). So, a higher priority event could not run until the lower priority event structure was finished. I ended up using single element RT queues and timed structures. But I still use user events quite a bit for sending triggers with data to other low priority threads. User events are very good performance wise in RT applications.

David

I am writing an application where functionally I can use user events or queues to sen messages (triggers)O between threads. On the other hand, since this is a real-time application, if there is a significant difference in the CPU processor requirements between the two, I would definitely want to pick the more efficient method.

I have implemented a solution using user events mostly because we use events elsewhere so the paradigm is more familiar. I am guessing that events add some small overhead versus queues, but is it much? Has anyone bench tested one versus the other? (I might need to do such a test myself, which is easy enough, but I thought someone might already have some results....)

Paul

[PaulL]

Thank you all for your replies.

Yes, we are using RT on a cRIO.

I think our application will be fine performance-wise since we only have one event structure (OK, most of the time) and I don't think we will ever have more than three events queued at any one time. On the other hand, if for some unforeseen reason the application started to run away, it would be good to be able to preempt the existing triggers with a stop trigger. I don't think this is possible with user events, so that is a strong point in favor of queues.

So I will probably implement a queue version of what I am doing (which won't take long at all), but since the events seem to be capable of doing the job (and they are certainly working functionally fine so far) I won't need to make a queued version today.

Thanks!

[Ton Plomp]

Is there a technique to monitor / control the size of the user event queue? fully...

You could set a 'time-out' for the event. When an eventstructure is activated and an event gets handled, the data includes the moment of the event, you could discard the event (eg. no processing) if the time is more than n seconds ago.

That way you could relatively fast empty the queue.

Ton