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.

>>
>> 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.

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.

>
>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.

>
>I thought Linux had better/proper threads now.
>

What's proper is subjective. Real unix guys use fork.

The real disaster with Linux pthreads is the interaction between
pthreads (which uses signal for process wakeup) and gdb (which
intercepts all signals). It is impossible to run a multi-threaded
program under load with the debugger on Linux. Sometimes Gate's
boys come through.

>
>:-). Only working with offsets is yucky. Working with direct pointers in
>shared memory is wonderful.
>

Yeah. It's called "multi-threading".

>
>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.

>
>> 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.

>
>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.

For what it's worth, Interbase implemented the first VMS threading
package. If ya gotta do it, ya gotta do it.

>
>Jim, I envy you. I always wanted to write a main memory database system :-)
>

It's the only way to fly. Now if AMD would get us a bigger
physical address space...

Jim Starkey