2

I'm writing a relatively large application for my company on Compact Framework 2.0 for a Windows CE device, and I'm working with a single CPU core.

Without getting into details, non-socket related work can, at worst case timing, have 10 or so threads running simultaneously.

This in mind, I'm using sockets for the first time in anything more than a small test application. This larger application will potentially be talking to 7 different ports on the same IP address (example with an obviously false IP, 1.2.3.4:4000, 1.2.3.4:4001, 1.2.3.4:4002, etc.), thus using 7 different socket objects.

Compact Framework 2, 1 CPU core, around 10 non-socket threads in a worst case scenario, and 7 sockets to program send capability and continuous receiving (to process/respond ASAP) for all of them.

I've been considering if asynchronous socket programming would only get me in trouble, with the default max number of threads being 25 (per core) for Compact Framework 2.0, and essentially how "clever" I have to get.

What are your recommendations? Asynchronous or synchronous socket programming, and any particular additional details you'd suggest, or if I am worrying about nothing.

Peter Lacerenza
  • 225
  • 2
  • 12

2 Answers2

1

I always recommend asynchronous sockets over synchronous sockets. Depending on the underlying subsystem, asynchronous sockets may not use any additional threads. Most of the time, using synchronous sockets requires manually creating threads to avoid blocking the UI (if you have one).

Having something else manage asynchrony is much easier than having to manage your own threads.

Whatever asynchronous sockets do won't impact the .NET thread pool

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
  • Completely agreed on your last statement. And the callbacks will use a thread each, but each will be incredibly short-lived, so it essentially doesn't matter. Thanks for the feedback. – Peter Lacerenza Jul 26 '12 at 13:33
  • Simply that if a thread, i.e. a callback method, is kept short in how long it takes to process, it is far less likely to have enough of an impact on the thread pool to cause issues or grief. – Peter Lacerenza Jul 26 '12 at 17:30
  • Any use of a thread pool thread has an impact on the thread pool. Despite being short-live, if you had a lot of simultaneous socket interaction, you could force the thread pool to create new thread pool thread. Sure, not likely; but if it does happen, you'd rather not have to re-write this code to fix it. – Peter Ritchie Jul 26 '12 at 17:33
1

As your device surely has limited memory and because .NET thread stacks consume 1MB of memory by default (committed, not just reserved) I think you should go with async IO because it does not block thread. Only your callbacks/continuations get posted on the thread-pool. There are few thread-pool threads so memory usage due to stacks is lower.

Remember, that async IO is mostly about not blocking threads, thereby saving on memory and OS handles. It is not about lower CPU cost (the opposite is true according to my benchmarking with network IO).

usr
  • 168,620
  • 35
  • 240
  • 369
  • I was concerned about max amount of threads that might be running simultaneously, but I hadn't realized that only callbacks (and functions called from callbacks) counted toward the threads in the thread pool, that was the bit of information I needed. It sounds like all I have to worry about is keeping the callbacks short and concise, and general thread safety of course. Thanks for your thoughts. – Peter Lacerenza Jul 26 '12 at 13:29
  • @PeterLacerenza, you got that exactly right. Here is a simple test: Put the app under load and pause the debugger. You should see no threads being paused somewhere. If that is the case you succeeded and are non-blocking. – usr Jul 26 '12 at 16:00