Re: Windows Mobile 5.0, .NETCFv2.0, and many sockets by Paul
Paul
Fri Jun 02 15:39:50 CDT 2006
Lowest CPU load will be multiple threads, I think. You could try to test
that. It's close enough on CPU load that I wouldn't decide on that basis,
anyway. As I said, I find having separate, disconnected threads a lot
easier to manage and to scale to bigger systems.
Paul T.
"stu" <stuboy@gmail.com> wrote in message
news:1149279519.352886.79530@g10g2000cwb.googlegroups.com...
>I guess by "more efficient" I mean lower cpu load. Thanks for your
> help!
>
> michael =)
>
> Paul G. Tobey [eMVP] wrote:
>> I'm not sure that either is "more efficient" in either case (more
>> efficient
>> at what?). It's much easier to read a multi-threaded application,
>> because
>> each thread is the "same" as all the others and is relatively simple,
>> there's no big loop running everything. It may be harder to debug, but
>> I'll
>> live with that.
>>
>> Paul T.
>>
>> "stu" <stuboy@gmail.com> wrote in message
>> news:1149194292.319930.178510@c74g2000cwc.googlegroups.com...
>> > With select() and a single thread you can block on all sockets at once
>> > until one of them gets something; select can listen to a whole list.
>> > Do you think that multiple threads is still more effecient that this?
>> > (As I said this is more of a curiosity, at this point.) Thanks for
>> > your input!
>> >
>> > stu =)
>> >
>> >
>> > Paul G. Tobey [eMVP] wrote:
>> >> Well, the scheduler has to schedule all of those threads, but, unless
>> >> you're
>> >> constantly receiving packets on all of the sockets, this will be more
>> >> conservative of CPU cycles than polling and, when everything is idle,
>> >> you're
>> >> using *zero* CPU cycles because all of the threads will be blocked
>> >> waiting
>> >> for data to arrive.
>> >>
>> >> Yes, when I say a single thread, I mean something that iterates over a
>> >> list
>> >> of open sockets, calling select() for each one in turn and then doing
>> >> something when a given socket has data ready to be received (or
>> >> whatever).
>> >>
>> >> Paul T.
>> >>
>> >> "stu" <stuboy@gmail.com> wrote in message
>> >> news:1149182369.893864.239800@h76g2000cwa.googlegroups.com...
>> >> > Yes, I agree async sockets were the poor choice for this. From my
>> >> > knowledge, using async sockets is encouraged in big .NET (this is
>> >> > what
>> >> > I've read, I don't have any experience in designing larger apps), so
>> >> > I
>> >> > figured the same was true for the .netcf.
>> >> >
>> >> > As for the single thread approach, are you talking about using
>> >> > socket.select() for all sockets or using socket.poll() on each
>> >> > individual socket and looping through the list (over and over and
>> >> > over)?
>> >> >
>> >> > As for the full thread approach, my fear is just eating up a lot of
>> >> > resources. Is it detrimental to have upwards of 20 receive()
>> >> > threads
>> >> > running around?
>> >> >
>> >> > Please let me know about the single thread approach (it is more out
>> >> > of
>> >> > curiousity at this point).
>> >> >
>> >> > Thanks!
>> >> >
>> >> > stu =)
>> >> >
>> >> > Paul G. Tobey [eMVP] wrote:
>> >> >> It's just my own preference, but I dislike asynch sockets for
>> >> >> situations
>> >> >> like this. Yes, you can use a single dispatch thread that
>> >> >> continuously
>> >> >> runs
>> >> >> and checks every open socket for activity that needs a response.
>> >> >> In
>> >> >> my
>> >> >> own
>> >> >> code, I'd be much more likely when using threading, to use blocking
>> >> >> sockets,
>> >> >> allowing a thread on which there is no corresponding socket
>> >> >> activity
>> >> >> to
>> >> >> sleep, freeing up those processor cycles for threads/sockets which
>> >> >> *are*
>> >> >> active. I think that this balances the load better. Since you're
>> >> >> on
>> >> >> a
>> >> >> very
>> >> >> resource-constrained device, you'll have to test to see what works
>> >> >> best.
>> >> >>
>> >> >> Paul T.
>> >> >>
>> >> >> "stu" <stuboy@gmail.com> wrote in message
>> >> >> news:1147971063.990909.83990@j73g2000cwa.googlegroups.com...
>> >> >> >I am looking for a good way to handle numerous sockets (1 UDP and
>> >> >> >as
>> >> >> > many as 20+ TCP child sockets) in WM 5.0 using C# and the
>> >> >> > .NETCFv2.
>> >> >> > Currently, I'm using async class and it works fine for small
>> >> >> > numbers
>> >> >> > of
>> >> >> > sockets; 1 UDP and up to 15 or so TCP child sockets. When I get
>> >> >> > to
>> >> >> > more than 15 (or so) I have an issue with other threads, using
>> >> >> > the
>> >> >> > threadpool, not running. Specifically, I have a managing thread
>> >> >> > (using
>> >> >> > the System.Threading.Timer stuff) that ceases to be called once
>> >> >> > the
>> >> >> > number of async calls gets rather high. Do the async socket
>> >> >> > calls
>> >> >> > block the threadpool threads? If so, is there a way to get
>> >> >> > around
>> >> >> > this, or the is the best idea just not to use async socket calls
>> >> >> > in
>> >> >> > this situation? I can't find any good documentation on how
>> >> >> > things
>> >> >> > are
>> >> >> > handled within the OS (a pointer to such documentation would be
>> >> >> > _greatly_ appreciated, too). I was at MEDC in Vegas last week,
>> >> >> > but
>> >> >> > failed to catch one of the VM Core developers to bug them about
>> >> >> > this.
>> >> >> >
>> >> >> >>From looking at other posts, it seems that Socket.Select() is a
>> >> >> >>much
>> >> >> > better method for handling a large number of sockets. When using
>> >> >> > select() is there a way to add another event that I can raise to
>> >> >> > get
>> >> >> > select() to come back or will it only respond to socket events?
>> >> >> > For
>> >> >> > example, I want to add another socket to the read array. I know
>> >> >> > in
>> >> >> > the
>> >> >> > old-school select() you could use generic events in the select
>> >> >> > array.
>> >> >> >
>> >> >> > Many thanks!!!
>> >> >> >
>> >> >> > stu =)
>> >> >> >
>> >> >
>> >
>