Hi Alex
All the comments are useful and appreciated. I am trying to think of
a way for the queue object to block the polling thread until the
queue is empty when it tries to add a message, but allow messages
from the UI thread to be added to the queue immediately without
blocking. If I can make it all internal to the queue class then the
queue can manage itself, rather than rely on correct implementation
in the external code where messages are added and removed. The queue
will also remove non-polling messages from the queue first, when its
DeQueue method is called, and then any remaining polling messages.
Charles
Hi, Charles
couple (triple) of comments
- queue can serve as starting point - you post there initial
(starting) message and user messages only
- thread checks the queue and processes next message. If it is user
one - you get what you want (you can send it) and don't need to hold
lock on queue anymore.
If it is <start poll> message - it sends first poll message and
saves state in internal member.
- when message was sent and processed thread locks queue once again
and checks if there are any message requests. If yes - they are user
ones and must be sent. If not, queue can be unlocked and thread can
check state - should it send next poll message or not.
In this scenario you don't need to hold queue for long periods of
time. Scheme could be expanded with arbitrary number of message
sequences. It reminds me a bit job scheduler, don't you agree?
HTH
Alex
Hi Jon
You certainly appear to have grasped the nub of the problem. But I
am guilty of misleading in one respect.
When I said that the polling messages are all the same, I wasn't
quite telling the truth. They rotate round about 16 different
messages, so the first poll is type 1, the second type 2, and so
on, up to 16. Then they start again. The sequence is important, and
there must not be any omissions. So I do need to carefully
synchronise the polling with the acknowledgements, as well as the
intermittent UI messages.
I like the idea of using an event to get the next polling message
(rather like the TxBufferEmpty interrupt from a UART). I am also
looking at creating a dedicated queue class to maintain the
messages, rather than use the standard Queue class, in particular
to allow me to insert messages ahead of any polling messages
(something the standard class doesn't allow). For this reason, I
am inheriting from CollectionBase rather than Queue, unless you
know of a better one.
Charles
[By the way, thanks for your continued help]
Jon Skeet [C# MVP] wrote:
I just need a continuous stream of polling messages to be sent
out. Each new message can be sent when the last one has been
acknowledged (by the remote end). However, the user can add a
non-polling message to the queue, in which case that is sent amid
the stream of polling messages.
In which case, the synchronization you need is between the polling
thread and the acknowledgement. You might want to do this with
events, for instance, firing an event whenever an acknowledgement
is received, and subscribing to that event with a delegate which
adds a message to the queue - possibly only if there isn't one
there already.
