Just a bit of musing

[claw at null.net]

On 11/03/97 at 02:45 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:
>> From: coder at ibm.net

>>   User IO arrives thru the Connector.  The connector is essentially a
>>   pool of threads which asynchronously manage the general pool of 
>>   outside connections.  
>>
>>   A seperate monitor is responsible for keeping the IO network tree
>>   happy.
...
> I am particularly interested in how your pool of threads manages socket
> connections.  Are these threads dynamically created to manage connections?  
> That is, do you n+1 threads managing your connections, where n is active 
> connections plus one to handle connection requests on the master socket?  
> Are sockets blocked or do you use some other method of activating threads?

This is really really crude, as its very long time since I looked at this
code:

  One thread watches the master socket and spawns connection sockets 
  from there as they come in.
 
  The child sockets then go into a pool (actually I think its a bag?) with

  a monitoring thread.  Any IO to or from a socket is then assigned on a
first
  available basis to a thread from a waiting pool of IO threads.  

  Should an IO request come in which does not have a waiting thread ready
to 
  execute it, a new thread is created to process the IO.  

  Should the number of IO threads significantly exceed the number of open 
  sockets, then IO threads are killed down to a base minimum.

  As such the total number of IO threads is proportional to the current 
  maximum rate of IO transactions thru the system.

I could be way off here, but I think the above is fairly accurate, well
sorta, maybe.
  
>> Well, given an SMP machine, with an OS that will intelligently distributes
>> threads -- that all semi happens for free with me (its not quite so good
>> as I try to minimise thread creations, as few to no current OS'es will
>> migrate a thread across processors for load sharing).  On the other side,
>> a definite design goal of my server is for it so support running in
>> clustered enviroments where the entire cluster presents a single
>> representation of a game.

>It is my understanding that many OSs that implement multi-processing will
>allocate one CPU for the OS and the rest of the available units to
>application threads.  NT 3.51 does this as well as many Unixes.  I thought OS2 
> used this model also.  (please correct me if I'm wrong)

AFAIK not even NT is quite this dumb (much tho I'd like to believe it). 
The process NT and OS/2 both follow, as well as most other MT SMP OS'es is
to allocate new threads to the least busy CPU.  I suspect that the source
of your confusion is that NT and OS/2 both (largely) have a monolithic
kernal (ie, a single thread).  As such, yes, that primary thread will get
allocated to one CPU at IPL.  However, even OS/2 doesn't have a purely
monolithic kernal any more, and so it will straddle multiple CPUs at IPL
quite nicely.

>It is also my understanding that NT 4.0 uses a different model and
>implements "load sharing" as you define it above.   I have heard rumors that
>Digital's 64-bit Unix uses the "load sharing" model.  Does anyone have any info 
>on this?

None here.  

--
J C Lawrence                              Internet: coder at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...