Re: Background thread with lower priority

Hi Daniel,

Thanks for the clarification. If I follow your personal opinion, I'll assume
that my app falls in the 99% category, so I will try to get it working
without lowering the priority :)

--
Jeffry van de Vuurst
CWR Mobility
www.cwrmobility.com
--
"Daniel Moth" <dmoth74@xxxxxxxxxxx> wrote in message
news:OlcNAnXHHHA.3616@xxxxxxxxxxxxxxxxxxxxxxx
Hi Jeffry

The blog entry I wrote in 2004 is something I still stand by today. Only
one thing has changed which is the number of threads in the threadpool
(not 256 anymore), but that doesn't detract from my point that much.

It has two questions and a statement:
Q1. "So if you change the priority of other threads in your app how will
they play nicely with the above four?"
Q2. "What will the results be if that happened to be one of your own
threads whose priority you lowered?"
S1. "if you are going to be creating threads and changing their priority
you must first be sure you understand the above and cater for them in your
design"

The first point is about knowing that you have 3 additional threads not
under your control. Design for that.

The 2nd point is about the GC running on whatever thread happens to be
running (*unlike* the desktop). Unlike the previous point, this has
nothing to do with other threads in your app (as others pointed out) but
has to be considered at the system as a whole (other threads are also
running on the system, as others pointed out).

Once you understand the implications of the above, my statement kicks in:
If you know what you are doing, go for it.

Nothing above is controversial. I can potentially be controversial by
saying that 99.99% of managed apps out there do not need to lower the
priority of any of their threads; in my *personal* opinion.

If you have any further questions regarding my blog entries please feel
free to email me. For questions specific to your needs/work, please
continue to use this group.

Cheers
Daniel
--
http://www.danielmoth.com/Blog/

"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:uJsv08UHHHA.1912@xxxxxxxxxxxxxxxxxxxxxxx
Correct, priority is irrelevent. The GC runs on the thread that
attempted the allocation that triggered GC, but the first thing the GC
does is suspend all other managed threads in the currently running
process, so if GC hap[pens in a worker, the UI still suspends.


--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--


"Ginny Caughey [MVP]" <ginny.caughey.online@xxxxxxxxxxxxxx> wrote in
message news:uJtEEuUHHHA.4056@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for the link. As I read it, since GC occurs on whatever thread is
running when GC needs collecting, the thread priority probably wouldn't
matter since that thread is running whatever its priority. At least
that's the way I hope it works.

--
Ginny Caughey
Device Application Development MVP


"Jeffry van de Vuurst" <jeffry.cwrmobility@xxxxxxxxxxxxxxxxx> wrote in
message news:uicqdLUHHHA.1240@xxxxxxxxxxxxxxxxxxxxxxx
Hi Ginny,

Here's the link:
http://www.danielmoth.com/Blog/2004/08/threads-and-threadpriority-with-net.html.

--
Jeffry van de Vuurst
CWR Mobility
www.cwrmobility.com
--
"Ginny Caughey [MVP]" <ginny.caughey.online@xxxxxxxxxxxxxx> wrote in
message news:uelq$0THHHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
Jeffrey,

I have desktop apps that run worker threads on lower priorities
without problems. I don't happen to have CF apps that do, but I'd
suggest just trying it. Do you have a link to Daniel's post? He
doesn't usually get things wrong so I should read it.

--
Ginny Caughey
Device Application Development MVP


"Jeffry van de Vuurst" <jeffry.cwrmobility@xxxxxxxxxxxxxxxxx> wrote in
message news:%23R9gpwTHHHA.3468@xxxxxxxxxxxxxxxxxxxxxxx
Hi Chris,

Thanks for your reply. I guess my question was not clear enough.

It's not the GC that causes the non-responsiveness. My assumption is
that the non-responsiveness is caused by running my background sync
on a thread with the same priority as the main thread. So when the
background sync starts, both the UI and the sync are competing for
the CPU cycles, right?

That's the reason I started creating my own thread and setting the
priority lower than the main thread. However, the blog post from
Daniel Moth gives me some concerns because it discourages changing
the priority of a thread because of unexpected behavior (mentioning
the garbage collection). At least, that is my understanding of the
article.

So maybe my question should be: is it ok to have a background thread
running on a lower priority so not to interfere with the GUI, or does
running on lower priority have unexpected side effects (like
mentioned in the article) and should be avoided?

Thanks,

--
Jeffry van de Vuurst
CWR Mobility
www.cwrmobility.com
--
"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:%23hmTTPTHHHA.2632@xxxxxxxxxxxxxxxxxxxxxxx
If a GC occurs, all threads in the process are suspended. Doesn't
matter what priority any of the threads are.

Are you sure it is a GC that's causing the non-responsiveness?


--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--


"Jeffry van de Vuurst" <jeffry.cwrmobility@xxxxxxxxxxxxxxxxx> wrote
in message news:eNdHtCTHHHA.4712@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

I have a CF 2.0 app that uses 2 background threads. 1 for polling
for a network connection and 1 for performing a background sync.

First I used the OpenNETCF BackgroundWorker for this purpose.
However, when performing a background sync the UI became
unresponsive. Now I changed it to a regular thead using:
Thread backgroundSyncThread = new Thread(DoBackgroundSync);
backgroundSyncThread.Priority = ThreadPriority.Lowest;
backgroundSyncThread.IsBackground = true;
backgroundSyncThread.Start();

However, I read here
http://www.danielmoth.com/Blog/2004/08/threads-and-threadpriority-with-net.html,
that chaging the priority of threads may be risky because garbage
collection could run on the low priority thread.

It's an article from August 2004 but does mention CF 2.0 beta 1.
Does this still apply? And if so, what are other ways to make sure
that the (potentially long) running background thread doesn't
freeze the UI? Is doing a Thread.Sleep(0) from the worker thread
effective? I've read different stories about the effectiveness of
Thread.Sleep(0)...

Thanks,

--
Jeffry van de Vuurst
CWR Mobility
www.cwrmobility.com
--

















.

Relevant Pages

  • Re: Background thread with lower priority
    ... "So if you change the priority of other threads in your app how will they play nicely with the above four?" ... Unlike the previous point, this has nothing to do with other threads in your app but has to be considered at the system as a whole. ... My assumption is that the non-responsiveness is caused by running my background sync on a thread with the same priority as the main thread. ... So maybe my question should be: is it ok to have a background thread running on a lower priority so not to interfere with the GUI, ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Background thread with lower priority
    ... It's not the GC that causes the non-responsiveness. ... the non-responsiveness is caused by running my background sync on a thread ... That's the reason I started creating my own thread and setting the priority ... lower priority have unexpected side effects ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Background thread with lower priority
    ... Priority to BelowNormal, it wouldn't get any time because the UI still has a ... Jeffry van de Vuurst ... the background sync takes about 20 seconds. ... Running it at a lower priority would allow the UI to get quantum before ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Background thread with lower priority
    ... *any* thread in the system with a higher priority than you and it is in the ... Jeffry van de Vuurst ... the background sync takes about 20 seconds. ... Running it at a lower priority would allow the UI to get quantum ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Background thread with lower priority
    ... If it's on a background thread it's going to compete for resources just like ... Running it at a lower priority would allow the UI to get quantum before the ... the non-responsiveness is caused by running my background sync on a thread ...
    (microsoft.public.dotnet.framework.compactframework)