Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2823 > unrolled thread

event queue issues

Back to article view | Back to comp.programming

Contents

  event queue issues bob <bob@coolfone.comze.com> - 2013-01-16 06:49 -0800
    Re: event queue issues "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-01-16 19:28 +0100
    Re: event queue issues Robert Wessel <robertwessel2@yahoo.com> - 2013-01-16 19:02 -0600

#2823 — event queue issues

It seems like most software nowadays operates on the concept of an event queue.

A thread continually monitors the queue, pulls stuff off and does it.

Are there any known issues and exceptional conditions relating to this?

For instance, one issue might be when the queue is full and you have an event you want to stick on it.  How should that be handled?

[toc] | [next] | [standalone]

#2828

On Wed, 16 Jan 2013 06:49:48 -0800 (PST), bob wrote:

> It seems like most software nowadays operates on the concept of an event queue.

No. Event is a waitable object. Queue is a container. As such a queue may
have some events associated with it, e.g. Not_Empty, Not_Full.

> A thread continually monitors the queue, pulls stuff off and does it.

No. Threads are waiting for a combination of events, which is also called
"non-busy" waiting (opposite to "busy" waiting = polling).

> Are there any known issues and exceptional conditions relating to this?
> 
> For instance, one issue might be when the queue is full and you have an
> event you want to stick on it.  How should that be handled?

Some implementation may provide wait+queue as an atomic operation, when
queue is for multiple producers. Others may first attempt to queue and then
wait for Not_Full signalled and attempt again. There is no best method,
because performance depends on the architecture [CPUs/cores, shared/local
memory etc] and the producer/subscriber scenario 1-n, n-1, n-m etc. This is
basically locking vs. lock-free.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2833

On Wed, 16 Jan 2013 06:49:48 -0800 (PST), bob <bob@coolfone.comze.com>
wrote:

>It seems like most software nowadays operates on the concept of an event queue.
>
>A thread continually monitors the queue, pulls stuff off and does it.
>
>Are there any known issues and exceptional conditions relating to this?
>
>For instance, one issue might be when the queue is full and you have an event you want to stick on it.  How should that be handled?


I wouldn't say most software, but it's certainly a common enough
pattern.  And we'd call it a work queue generally, not an event queue.

As for "continually monitoring" - usually the consumer thread(s) would
block if the queue were empty.

The most common approach for attempting to write to a full queue is
for the producer thread to block until there is space.  The detail may
vary (often more than one producer can get woken up, and if there's
not enough free space in the queue, some of them may have to block
again).  Also fairly common is to discard events when the queue is
full, although obviously that only works if you can live with some
items going missing.  A fair number of apps just keep growing the
queue and hope that they won't run out of storage and die a horrible
death (that approach isn't generally recommended, but it is
unfortunately common).  Sometimes there are things you can do to
consolidate entries in the queue.

In any case you have to consider failures like the consumer thread(s)
getting stuck, and things like that, plus all the normal
multi-threading issues.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web