Re: threading (Re: ideas)

On Wed, Jun 14, 2000, Jon Kay wrote:
> Squid has reached a certain point of high stability and SMPs a certain
> low level of price where it might be worth taking the plunge and
> adding threading, at least on an experimental basis, but it is
> important that it be done cautiously.
>

[snip]

> OK, so what is the 'right' way to do threading? Miminize its impact.
> Minimize the number of locks (rpc calls count as locks) and the
> numbers of times that a context switch will happen in the common case.
> Use locking rather than rpc calls. Try to keep processing of a given
> system 'request' in one thread of control.
>
> In the case of Squid, I would suggest processing requests very nearly
> as much as is already done in a single thread of control, and adding
> thread-conscious code at three points: request dispatch from
> comm_select(), storeGet()/storeLockEntry(), and where diskio threads
> off now. Request dispatch should probably be the only place where
> threads are created, and only if 'necessary'. This is the minimum
> needed to take advantage of SMP and processing requests while waiting
> for disk.
>
> Those incremental measures alone will provide no shortage of debugging
> challenges, but it's probably about as good as you're going to get.
>
> No doubt you would have to change some data structures to be
> associated either with a request or with a storeEntry.

Thanks for your input. The current design looks like it will be centred
around multiple processes rther than multiple threads (although if
written correct from the beginning I think turning it from mulltiprocess
to multithreaded mightn't be that difficult..)

In my thread implementation notes I split up a comm loop per CPU
and then whatever threads were needed to implement the FS code.
But threads aren't entirely portable so I'm going to work with Henrik
to find out a efficient multiprocess design. I think there will be
similar issues as with threading if sysvshm/semaphores are used
for IPC when it comes to locking and so on.

As for StoreEntry changes, thecurrrent proposal doesn't centre everything
around a StoreEntry, rather it is request-centric. Both Henrik and I will
keep the list posted. :-P

Adrian

-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@creative.net.au>	rest of the evening. Set a man on fire and
				he's warm for the rest of his life.