John M McIntosh johnmci@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