Hi, I am kind of new to multithreaded programming and network programming, so I had some difficulty with the examples. Can you confirm an epiphany I had? - I was thinking I had to use the asynchronous functions to handle multiple clients, now I understand that you can achieve same things with synchoronous ones w/ threads and you can write equally efficient code?. (It is only a different pattern; some people find the code more manageable the async way, since they don't need to handle threads themselves.) Is this new understanding true? - If no (if there is some efficiency difference), is it significant? (Otherwise, for the initial prototype of our software, I may use still use synchronous sockets w/ threads, since I am still not very comfortable with async.) Best regards, Ozgur (Oscar) Ozturk www.DrOzturk.com Phone: +1 (908) DROZGUR i.e, +1 (908) 376-9487
Unfortunately threads on most OSs are as much a resource as memory.
Using them as if they are "cheap" is typically a recipe for poor
performance. Read some of Herb Sutter's recent articles on DDJ Online
on using threads effectively, especially on multicore CPUs. Have a
look at Intel's Threading Building Blocks library.
In POSIX-land (where I live) at the simplest, I would dedicate a
thread to all socket I/O (via select, poll, epoll, pick your poison);
running a thread per connection scales poorly (not to mention would
limit the number of concurrent connections, depending on your OS --
definitely under Linux). Typically you'd dispatch the work to another
pool of threads. Anything that will block for a while I'd like to
isolate to a thread, keeping CPU-bound work to a fixed-size thread
pool (task-oriented rather than thread-oriented).
Concurrency is an area that I think languages like C++ and Java make
it terribly difficult to well, but then I'm on a big Erlang kick right
now, where this stuff is just a breeze.
On Thu, Jul 23, 2009 at 2:26 PM, Ozgur Ozturk
Hi, I am kind of new to multithreaded programming and network programming, so I had some difficulty with the examples. Can you confirm an epiphany I had? - I was thinking I had to use the asynchronous functions to handle multiple clients, now I understand that you can achieve same things with synchoronous ones w/ threads and you can write equally efficient code?. (It is only a different pattern; some people find the code more manageable the async way, since they don't need to handle threads themselves.) Is this new understanding true?
- If no (if there is some efficiency difference), is it significant? (Otherwise, for the initial prototype of our software, I may use still use synchronous sockets w/ threads, since I am still not very comfortable with async.)
Best regards, Ozgur (Oscar) Ozturk www.DrOzturk.com Phone: +1 (908) DROZGUR i.e, +1 (908) 376-9487
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
- I was thinking I had to use the asynchronous functions to handle multiple clients, now I understand that you can achieve same things with synchoronous ones w/ threads and you can write equally efficient code?.
In addition to what Oliver said, you'll get in trouble when you'll try to add some time-out or cancellation functionality with sync. i/o.
participants (3)
-
Igor R -
Oliver Seiler -
Ozgur Ozturk