Lex wrote:
> > Do you have a *rationale* for why the existing 1-semaphore 
> > primitives are insufficient?  Certainly the existing primitives
> > are already implemented on all platforms, they are fast enough to 
> > saturate a 10 MBit network, and they are equally good under 
> > multithreaded access.

John replied:
> You have thread (A) that reads data from a socket, and thread (B) that
> writes data to the same socket. Thread (A) waits on read with 
> Sempahore X then thread (B) happens to wait on write on Semaphore X.
[... More explanations deleted...]

Contrary to the argument given in Johns post, two semaphores at the
primitive level are *not* required. One is completely sufficient since you
can always write yourself a MultiThreadSocket that has a read/write
semaphore and an additional i/o process ala:

MultiThreadSocket>>runIOProcess

	["waits for any state change"
	semaphore wait.
	(self primSocketReceiveDataAvailable: socketHandle)
		ifTrue:[readSemaphore signal].
	(self primSocketSendDone: socketHandle)
		ifTrue:[writeSemaphore signal].
	] repeat.

which might be slower than using two (or more) semaphores at the primitive
level but gives you the chance to actually modify the behavior from the ST
side rather than black-boxing it in a primitive.

> PS Three semaphore model is good enough to saturate 100MBit 
> via 500Mhz PB.

How does the one-semaphore model do in comparison?! And, (the most
interesting question for me) how does something like the above
MultiThreadSocket perform?! Can you post the benchmarks you've been
running?!

  - Andreas