[Q][Unix][Sockets] Looking for explainations of 3 semaphores and error states.

Lex Spoon lex at cc.gatech.edu
Wed Jul 26 13:44:12 UTC 2000


John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> >> 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.
> >> 
> > 
> > Two gripes about this scenario.  First, why would you have a threading
> > situation like this in practice?  Second, why stop with a reader and a
> > writer--suppose two threads are both writing data to the same socket
> > (probably a UDP socket)?  Or, what if one thread is watching for normal
> > closes, and another is watching for errors?
> 
> May I remind you the question is one or more semaphores? The example doesn't
> have to elegant, just something to show one semaphore is insufficient. In
> math or physics I only need one counter example to disprove a theory. I
> think I've give an example to show one semaphore is a problem. Since the
> objective is to have millions of people use Squeak I'm sure someone will
> think my solution is elegant.
> 


One counterexample would be enough, but it has to be one I agree with! 
I argued that your example isn't something we actually need to support,
and I furthermore proposed a way to solve it anyway without using more
semaphores.  So to convince me, you need to either refute those two
arguments or find another counterexample.

Also, I had thought my UDP example was a straightforward extension of
the problem and solution you've been describing.  Isn't a major goal to
support multithreaded access to a single socket?  I wonder why one would
stop at 3 threads, once they've decided that 1 isn't enough.

Regarding performance, I have a standing question against whether the
3-semaphores interface would really better performance than simply
tuning the image and VM.  As far as I can reconstruct the reasoning, the
idea is that you won't waste time trying to write when it's reading that
has become available, and vice versa.  Is that about right?  Well,
consider that trying to write and failing can be made an extremely fast
operation.  Futhermore, I'd guess that most applications tend to know
which operation they are waiting for at any given time.  In fact, many
services will naturally refuse to read any new data until they have
finished spooling out their response to the last query.  For such
applications, which I'd tentatively guess are the majority, it is
possible to guess the appropriate operation every time.


Theory aside, I eagerly await more performance data.  Although, I hereby
whine that people shouldn't performance tune before they have at least
measured a problem!  Anyway, it will be interesting to see.  I betchya a
1-semaphore VM can saturate a 100MBit network, if a 3-semaphore VM can,
but, we shall see.


Overall, I still think the original VM interface was fine.    Of course,
even if everyone agreed, we'd faced with a cost analysis of switching
the Mac port from 3 semaphores -> 1, versus switching all the other
ports from 1->3.  Note, though, around 10-20 man-hours have already been
put into updating the Unix port, and it probably isn't finished yet.



	-Lex





More information about the Squeak-dev mailing list