Re: [boost] 2. It is unavoidable to use threads

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-09-13 15:44:09

Jeff Garland wrote:

> On Mon, 13 Sep 2004 00:19:07 -0500, Aaron W. LaFramboise wrote
> 
> 
>>I'm not sure I follow you here.  The limitation is specifically this:
>>#define MAXIMUM_WAIT_OBJECTS 64     // Maximum number of wait objects
>>That is the maximum amount of objects you can pass to
>>WaitForMultipleObjectsEx().  In the case of serial ports, you only need
>>one of these per port.  These are reusable, and several user-visible
>>events may depend on a single system object.  Outside of the networking
>>problem, which has the separate solution (APC callbacks, which as 
>>far as I know, are unlimited), it is difficult for me to see how you 
>>would use more than 64 of these system objects.
> 
> 
> Lets say you have a piece of hardware and you want to monitor a bunch of
> serial ports.  Let's say you have 2 timers per serial port plus the port
> itself.  Your total capacity is ~21 port. Then you have a few socket
> connections and things are reduced even more.  Let me put it another way -- I
> know of 2 projects that have teetered on the brink of this limit.  In both
> cases, it was a huge design issue...

I think I might be miscommunicating.  Normal events will not require an
object handle slot.  The only things that will require these are
resources that can't be use APCs/completion ports, Windows messages, or
the timeout.  All of the obvious things such as sockets, files, and
timers are handled by the aforementioned features.  The only things left
over, that will require these slots, are notification handles, processes
and threads, synchronization primatives, and a few miscellaneous odds
and ends that Win95 can't do with APCs (such as serial ports).

In general, I think the feeling is that 64 is adequate because you're
probably doing something wrong if you think you need more than this.
There may be a very few rare cases when this is insufficient, such as if
you were monitoring 70 directories for changes at once, but for people
who need to do that, I don't feel bad about requiring them to do
something special.  (I'm not even sure if Windows has the technical
capability to do that.)

>>For timers specifically, I do not think there is any need to use any 
>>of the Win32 timer facilities at all.  WaitForMultipleObjectsEx()
>> has a millisecond timeout parameter which hopefully is 'good 
>>enough' for timing needs.  In my implementation, timers are 
>>organized into a queue, the difference between now and the timer on 
>>the top used for the timeout value.
> 
> That's good -- ACE uses timer queues to solve this problem as well.  What I
> was getting at is that the OS facilities have to be extended or you will run
> into the timer limit very quickly.

OK.

>>I wouldn't be opposed to a higher level multiplexor abstraction that
>>builds on the core multiplexor abstraction that did spawn extra threads
>>as needed, though.
> 
> 
> That's what I think we should strive for.  

OK.

>>>Well, I think there might need to be some interface here.  For example, it
>>>would be nice for the multiplexor would have a pool of threads and dispatch
>>>each event to execute in a thread.  The size of that pool might be '0' in
>>>which case the multiplexor uses its' thread to dispatch in -- hence
>>>degenerating into a single-threaded arrangement. 
>>
>>I agree.  However, I think this could be designed best by having the
>>core multiplexor thread-ignorant, with a separate wrapper component
>>around that core doing the thread management.
> 
> Perhaps, but I don't see how even the core multiplexor can be implemented to
> operate in MT environment without locking.  It could be that we can have a
> locking policy that can be null in the case of single threading...

This is an area I am not entirely sure of.  In my own designs, I have
always used own demultiplexor object per thread, and there is little to
be synchronized.  I have found value in having the 'register event
listener' method be thread-safe, allowing other threads to feed events
to a thread in a direct manner.  Beyond that, though, I don't think the
demultiplexor core needs to know much about threads.

Aaron W. LaFramboise