----- Original Message -----
From: "Jim Starkey" <jas@...>
> At 12:46 AM 9/20/02 +1000, you wrote:
> >
> >You are saying that fixing shared memory in physical memory is a bad
idea?
> >and that this is what the AT&T unix developers did?
> >
>
> Yes.

Ok. Sorry it took so long to understand what you meant.

I wonder, in these days of the v.cheap memory, whether it's not time to
remove virtual address translation from operating systems. Do you ever
really want *anything* to swap out to disk...? Hmmm, kernel protection would
still be required - perhaps two address spaces are required. Maybe the
kernel can have all physical addresses below/above a certain number.

> >> Inter-process synchronization requires kernel intervention. A
> >> kernel primitive is better that a process level wait/wakeup
> >> mechanism as it gives better information the scheduler, eliminating
> >> unnecessary process wakeups and context switches.
> >
> >I hear you but on large unix box with 4, 8 and more processors it's quite
> >possible that the other processors are already live and no context switch
> >happens. People have told me that using spin-locks is much better than
using
> >semaphores. I can see how thread synchronisation (throughput with
threads)
> >could be even better considering the enlightened scheduler and reducing
> >context switches. I think spin-locks can work for threads too, though.
> >
>
> I spin lock (close cousin to infinite loop) is not a generally
> useful technique, and can only used used on something that another
> process or thread will have for a tiny period of time, or a live
> lock develops. Spin locks are mostly used to control access to
> a queue for blocked thread/processes, the glue for a more useful
> schema.

I got ya. I've seen those baby's morph into their "close cousins" on
occasion!

> The bottom line is that a process/thread can "wait" in a processor
> loop for so long before total system efficiency is destroyed. Long
> before then a process or thread must ask the operating system to
> put it to sleep.

Could spin for a fixed time/number-of-iterations and then use a different
synchronisation mechanism. It would probably be worthwhile to log this when
it happens because if it happens too much then the spin-lock should probably
be removed.

> >Can't inter-process synchonisation work exactly the same way as
> >inter-thread synchronisation - through shared memory and test-and-set
type
> >operations - and so not resort to a system call?
> >
>
> Only if you don't mind violating process isolation.

:-). That's what we want to do. That's what shared-memory is all about.

>[ snipped a bit about linux pthreads - thanks for the info]
> >
> >:-). Only working with offsets is yucky. Working with direct pointers in
> >shared memory is wonderful.
>
> Yeah. It's called "multi-threading".

Hmmm.

> >With multi-process model with shared memory, errant processes can only
> >scribble on their own private memory and pages of shared memory currently
> >mapped.
> >
> >With multi-threaded model, all memory is shared between the threads. An
> >errant thread can scribble over not only it's private memory and shared
> >structures but "private" memory of other threads too.
> >
>
> Trashed memory is trashed memory.

Come on. You keep bringing up process-isolation and then, just when
process-isolation going to give you something, you say this :(.

> >> Netfrastructure has synchronization objects on about two
> >> dozen classes for a total about a 30 types of things being
> >> synchronized. The synchronization object resolves read/read
> >> contention (sic!) with interlocked increment/decrement
> >> instructions, resorting to pthread and critical section
> >> synchronization of thread wait queues. The goal, usually
> >> achieved, is to satisfy a web request without a thread
> >> or context switch.
> >
> >You kinda lost me hear, Jim.
> >
>
> The strategic question is the scope of a lock. Current Interbase/Firebird
> has a single mutex for the entire engine. It could be reduced to a
> mutex on the memory manager (see previous reference to "hoard"), another
> on the meta-data, another on the cache manager etc. This would allow
> more parallelism. But changing the locking from "meta-data" to
> individual tables would give more at a cost of more difficult
> analysis (deadlock avoidable) and programming. Netfrastructure
> pushes the granuality as low as possible, but requires a locking
> scheme where uncontested shared access can be granted essentially
> for free.

Would you mind saying what strategies/techniques you use to avoid deadlock
in Netfrastructure?

> >The main reason that we use multi-process/shared-memory model at work is
> >that threads were not an option when the project(s) began. I've been
> >thinking of recommending single-process/multi-thread as the "architecture
of
> >the future" at work.
> >
>
> I'm sorry. You aren't really using multi-process/shared-memory. You've
> implemented threads. Congratuations.

Hmmm. That's a very interesting way of seeing it! Thanks, I'll have to think
about this.

Steve.