Re: ideas

Adrian Chadd wrote:

> I don't think there's a difference. What I was trying to get at is that
> if the code is written to enforce all 'lets' in a request/reply on
> one CPU/thread then you don't have to worry about cross-thread
> communication and locking, which would make things a lot faster.
> How this would perform in real life is unknown to me right now.
> I am thinking that at sufficiently high loads the requests will be
> spread across the IO threads and will 'balance' out.

Ok.

> I'm more worried about inter-thread locking. You really can't have
> much mutex locking in the system I've described, because the main loop
> has to be non-blocking. For cross-thread communication I can only
> think of a form of message queue which would work OK, but might
> be expensive..

There are non-blocking mutexes. See pthread_try_lock.

And you can of course use any of the normal IPC mechanisms like sockets,
pipes or whatever if that isn't enought.

But yes, keeping the flow within a single thread is most effective and a
lot simpler.

> I don't know that it needs to be fully distributed. For example,
> if you have two CPUs, and you are swapping in an object on CPU A,
> you then have a new request come in on CPU B and the request requires
> this same object, you migrate the request across to CPU A and then
> it can hook into the existing storge manager session.

The point is if there is a request for another object at a same time
then all work for that object is distributed to the thread handling the
request forwarding for that object. There is no central thread handling
all store operations.

> Hmm. How this is actually cleanly implemented isn't known.

Memory tables with small granularity locks. For example a hash with one
lock per bucket. Collisions are best handled by deferring the operation
for a short while.

If we go for a multiple-process then the situation gets quite different
since you cannot share resources (memory and/or filedescriptors) at that
level between two processes in an efficient manner. (well, both are
shareable, but not that easily or very portable)

I think I still prefer the multiple-process design. It is more portable
(well not to DOS and other single-task OS:es) and more reliable, but
requires more effort in design to not make IPC a major bottleneck.

Hmm.. how is the threading support on *BSD nowdays? Is it SMP capable
for a single process wrt networking and disk I/O? The parts we are
talking about basically requires kernel threads to at all scale on SMP,
and last time I looked OpenBSD/FreeBSD did not support that..

/Henrik
Received on Mon Jun 12 2000 - 12:59:58 MDT