Re: async queue?

[Mark Mielke <mark mark mielke cc>]

On Tue, Dec 11, 2001 at 04:02:12PM +0100, Mathieu Lacage wrote:
> le mar 11-12-2001 à 14:33, Mark Mielke a écrit :
> > One mutex, and two conditionals, as opposed to one mutex and one
> > conditional. For 'overhead', it's only a few extra bytes to ensure
> > that one thread doesn't runaway, while the other thread makes its
> > best effort to compete.
> The "overhead" is in the system call. I personally do not consider this
> to be "overhead". I was merely playing devil's advocate for those who
> consider threads to be _evil_.

There are a fair share of these people. They do have valid reasons for
hating threads as well. Most of the reasons why people hate threads,
though, really relate to the fact that most other people don't
understand them, do not make proper use of them, and then complain
because they actually end up sacrificing performance by using
threads. :-)

The overhead can be completely avoided if no "max size" is specified.
(perhaps max size of 0 means this?) However, the danger of the
producer out-producing the consumer would still remain as a known risk
in this case.

> > > As a side note, you refered to the "Async Queue" and what you want is a
> > > "Sync Queue" so, I guess you definitely should create your own version
> > > of a "Sync Queue"
> > This is rather interesting of a suggestion, however I'm not certain
> > that it is correct. I don't want a 'sync queue', except under the
> > situation that the 'async queue' would grow without bounds.
> Well, this is the definition of a sync queue for me: a queue which has a
> maximum size and which blocks when it reaches that size and a minimum
> size (emptiness obviously) and which blocks when it reaches that size.
> It is effectively synchronous. I guess you probably have another
> definition...

True. I suppose I would usually assume that a synchronous queue was
one which would block a push, until the item had been popped on the
far side. Compare this to synchronous reads/writes to the file system.
The operation would only complete, after the data had made it to the
disk.

The only benefit of such an implementation, is that one is able to
ensure that the data makes it to the far end. With the file system,
asynchronous reads/writes implemented using ASYNC I/O if available,
allows several operations to be pending at once, with notifications
available upon completion. One of the significant gains available from
asynchronous I/O, is that more than one item could be processed at a
time. This would be similar to the consumer thread popping several
items from the queue at a time.

During normal circumstances, one would usually ensure that the
maxlength of the queue was sufficiently high that it was never usually
reached. It is an electric fence that ensures that things don't run
out of control. As an example, setting it to 1024 for a queue that
will only contain very small items, is probably perfectly reasonable.
For items that may be several Mbytes large, setting it to 8 or 4 may
be reasonable. The danger is that the producer could monopolize the
processor, filling RAM, thereby causing the performance of the entire
system to suffer, ensuring that the consumer will never be able to
catch up.

In real world circumstances, what would more likely happen, is that
the producer would fill the queue with a bunch of items, and then sit
idle when complete. The consumer then has a chance to begin emptying
the queue, and completes sometime later. The effect, is that using
this model, this process has not been optimal. The advantages of
threading have not been utilized. One may as well have ran the
producer in a single threaded environment, fill the queue, and when
complete, replaced the produced with the consumer, and empty the
queue. At least then, the overhead of threading would be eliminated.

mark

-- 
mark mielke cc/markm ncf ca/markm nortelnetworks com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/