Re: apache style squid?

--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

> > I think keeping few thousands of threads stand-by will create lots
> > of wasteful
> > overhead as they are still considered by scheduler even if idling.
>
> Only if it's a REALLY bad scheduler. If they are sleeping on some
> mutex, then they shouldn't be on the run queue.

 Well, to detect that thread is idle on a mutex, scheduler has to do some
 work, things just doesn't happen byitself ;) even if the overhead is neglible
 I still don't see the point in keeping idle threads around.

> > Don't be sure. even "Count++" is not atomic and can trash alot if
> > not surrounded by mutexes.
>
> It doesn't matter if it's not atomic, as long as the write is
> atomic. There's only one writer so when doing
> x = var
> ++x
> var = x <----- atomic
>
> only the last line needs to be atomic, and I don't know of any
> machines that allow a context switch inbetween writing the bytes of a
> word variable. :)

    var=3

    CPU1 CPU2
    x = var (3) ...
    x++ (4) x=var(3)
    var = x (4) x++ (4)
      ... var = x (4)

  You've got var wrong. Also applies for 1 CPU with thread switch after x++
  Of course, as you insist on single writer, this would is avoided.

> I think you're missing the point. There is only one writer. It's a
> pre-condition. You simply set it up so there is only every one writer
> for an object, and voila! it happens.

 OK, I missed that. But it's quite hard to setup and would add other
 kind of overhead, IMO. Also, this doesn't scale well on Cray ;)
 Why I dislike single writer is because it is most simple and straightforward
 to code threads from accept() to the last close() as independant and
 all equal, all searching and updating metadata as needed, without a need
 for mama-thread... or even worse - mama-process...
 How would you arrange single writer to index database, when you can
 add an object to it only after successful connect is made and thus service
 thread long running already? Would you pass the object along to mama
 via IPC only to make an linkedlist update? how would you lock mem object?
 unlock it later? You'd need to keep track of every and all threads in mama,
 instead of fire-and-forget...
 
> > > Process model -
> To be honest, I'm (like some other people here :) focused on my
> situation, which is linux boxen. This means for me:
> processes are as fast as kernel threads.
> The upper limit is huge (8000 odd).
> I can do 45,000 context switches / second on a mid-range box.
>
> This means for me that process model is definately viable..

 I see. For Solaris this is definitely no-go..
 
 Somebody could test, how OS would behave when having about 2000
 processes doing shared mem locks and trying to do something useful.
 You see, when you have very many processes, kernel has to do much
 more work in scheduler to find next runnable process. Context switches/sec
 are not the only killer...
 
> > > Thread model (with locking)
> > in theory fastest possible.
>
> No, in theory there's no difference. The issues between kernel
> threads / user threads / processes are _ALL_ issues of the underlying
> OS. There is little inherent speed difference. It's purely the
> implementation details.
 hmm. Sounds very far-reaching. But we were talking about threads vs
 processes here, thus about real world. I think I should have said
 in theory fastest implementation possible...currently? ;)
 
> > > Mixed process/thread model
> > most complex.
>
> Note that as far as I can see, there is very little code difference
> between the process / thread /kernel thread implimentations. If you
> code for the hardest (process), then the rest will be trivial in the
> extreme.

 I'd say process/thread models are quite different and it is not trivial
 to switch unless written threads in mind.
 Well, actually I see, and this I meant with this mixed model is that when
 writing threaded model, for Linux you could define the process being
 threads. Then the rest is similar alot.
 

  BTW, there's one model not mentioned:
          Mixed process/select() model
 I'm afraid this would be most complex to make right, unless each
 process is made totally independant from the others and processes
 only share common knowledge about disk contents and each process
 handles its private cache directory.

 ----------------------------------------------------------------------
  Andres Kroonmaa mail: andre@online.ee
  Network Manager
  Organization: MicroLink Online Tel: 6308 909
  Tallinn, Sakala 19 Pho: +372 6308 909
  Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
 ----------------------------------------------------------------------

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:43 MDT