Subj : Re: Futexes are wrong! (Are they?) To : comp.programming.threads From : David Schwartz Date : Wed Jun 15 2005 05:17 pm "Jomu" wrote in message news:1118876320.279688.327530@g47g2000cwa.googlegroups.com... > And you are very selective in replying :). I reply to that which I most disagree. > As I say, and I will repeat this last time in this thread - landscape > is moving. What was unthinkable five years ago, works today. 10,000 > threads running on home PC is piece of cake now, impossible five years > ago. Even more efficient synchronization is being developed and spread > as we talk. However, people need their computers to *do* more. If you're talking about an Internet server, the Internet is growing. People need faster PCs to get more work done, handle more clients, and handle them better. Not to make inefficient architectures tolerable for the same load that can handily be served by efficient servers. > I would think about exact way of solving 10k client when I need it - > for hundreds and up to few thousands I feel no drawbacks of t-p-c > approach - my programs work and they are almost under noticeable on > common PC. For 10k I will probably need some auxiliary level for > serialization of requests for some specific resources, but context > switch is surely nothing to be afraid, anymore. And it would be even > less noticeable as time passess. Another problem with t-p-c is it means that if a thread ever blocks for any reason, a client is stalled. With thread pool, you can block a thread if this makes more sense. > And "thread is personification of client" (in t-p-c) is something I > really like as it helps me, and other people > reading/perusing/justenjoying my code to understand/maintain/extend > what I wrote. If you need your "one advantage", think about that. Think > about plainly writing what you really need to be done, not multiplexing > it in some event driven interface. No select, no pool, kqueue, epoll... > just simple blocking I/O ;). How's that about > compatibility-over-various-platforms? One concept which works > everywhere, same - blocking I/O :). The I/O is easily encapsulated in an I/O class or library. People looking at the code don't have to even see the I/O code unless they are interested in some detail about it. All they see are methods to handle the receipt of data. I've seen code of both types, it's possible to write really bad or really good code with either model. > And, as I said.. I am lookig forward to see you in t-p-c as it becomes > more and more O(1) all around :). It will not happen, there is *no* advantage at all. One thing you can do with a thread pool, when it makes sense and you don't absolutely need the performance, is dedicate a thread to a client. You can even do this in the 80% of the code that only accounts for 20% of the performance. And you never have to worry about a thread accidentally blocking and killing anything. If a client goes three minutes without sending a byte of data, having a thread blocked in 'recv' gains you nothing at all. Not a thing. DS .