Re: Background thread with lower priority

Ok, thank you all for you suggestions and explanations!

About the UI waiting for the background thread. That's no issue to my
knowledge. The UI doesn't wait on the background thread to complete, they're
independent.

I see your point that the background thread doesn't get any time as long as
the UI is doing anything. But as I understand it, even if I would set the
Priority to BelowNormal, it wouldn't get any time because the UI still has a
higher priority, right?

I'll try your suggestion of doing some yielding in the background thread.

Another quick question. If I go for the Sleep(0) option would you suggest to
use the OpenNETCF BackgroundWorker again or should I just stay with creating
my own threads? In other words, does the backgroundworker have any
(performance/memory) advantage over creating my own threads?

Thanks again,

--
Jeffry van de Vuurst
CWR Mobility
www.cwrmobility.com
--
"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:eN2M$uUHHHA.1188@xxxxxxxxxxxxxxxxxxxxxxx
I agree - I'd see if a few yields (Sleep(0)) in the worker thread alleviate
things.

Lowering the priority runs the risk of the worker taking an eternity to
complete.


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


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:uiqNafUHHHA.320@xxxxxxxxxxxxxxxxxxxxxxx
So, you want to prioritize that below the rest of the UI. That's fine,
but you should understand that the priority means that, as long as the UI
is doing *anything*, your background thread will get *zero* time (not
just a small amount of time, not almost no time, absolutely no time).
You certainly don't want to set its priority to lowest, or I wouldn't
want to set its priority to lowest, at least. If the UI is waiting, at
any time, for something from the background thread to be complete, it
will almost certainly wait forever. You might try setting it just below
the priority of the UI thread, or you might alter the code, leaving the
priority at the default, so that it periodically goes to sleep for a
little while.

Paul T.

"Jeffry van de Vuurst" <jeffry.cwrmobility@xxxxxxxxxxxxxxxxx> wrote in
message news:%23zzHTXUHHHA.5000@xxxxxxxxxxxxxxxxxxxxxxx
Well, the background sync doesn't completely lock the UI, it just makes
it a lot slower. It does quite a lot. It does some local database calls,
does some webservice calls and if there's new data, it loops through all
the records and saves them to the local database. This is quite an
intensive process. However, when checking for updates and there's
nothing new, the background sync takes about 20 seconds.

Posting the complete code of what the sync does goes too far. Here's my
code to start the thread:
private static void StartBackgroundThread()
{
Thread backgroundSyncThread = new Thread(DoBackgroundSync);
backgroundSyncThread.Priority = ThreadPriority.Lowest;
backgroundSyncThread.IsBackground = true;
backgroundSyncThread.Start();
}

And here's the DoBackgroundSync method:
private static void DoBackgroundSync()
{
_backgroundThreadRunning = true;

// Wait a while so that the automatic backgroundsync won't interfere
with the startup of the application
Thread.Sleep(60000);

// While the EnableBackgroundSync property is set to true continue to
sync
while (_enableBackgroundSync)
{
if (!BackgroundSyncRunning & !_syncRunning)
{
if (!_connectionManager.IsConnected)
{
try
{
_connectionManager.CheckConnection();
}
catch (Exception ex)
{
TextLogger.Log(TextLogger.LogLevelType.Error, "SyncManager
BackgroundSync Connection error: {0}", ex.ToString());
}
}

if (_connectionManager.IsConnected &&
!AppSettings.InitializeApplication) // don't perform a backgroundsync
while initializing the app
{
_backgroundSyncRunning = true;

// First, stop automatic dispatching
if (!AppSettings.WorkOffline && _requestManager.Running)
StopAutomaticDispatch();

try
{
StartSync(null);
}
catch(Exception ex)
{
TextLogger.Log(TextLogger.LogLevelType.Error, "Error during
Background Sync: {0}", ex.ToString());
}

while (BackgroundSyncRunning)
{
// Wait for backgroundsync to finish
}

// When finished with Sync, restart automatic dispatching
if (!AppSettings.WorkOffline && !_requestManager.Running)
StartAutomaticDispatch();
}
}

if (_enableBackgroundSync)
{
TextLogger.Log(TextLogger.LogLevelType.Info, "SyncManager
BackgroundSync: sleeping for {0} minutes", AppSettings.SyncInterval);

// Put the thread to sleep for the interval
Thread.Sleep(AppSettings.SyncInterval*60*1000);
}
}

_backgroundThreadRunning = false;
}

The call to StartSync(null) does all the hard work :).



--
Jeffry van de Vuurst
CWR Mobility
www.cwrmobility.com
--
"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:%23yKDc3THHHA.3616@xxxxxxxxxxxxxxxxxxxxxxx
If it's on a background thread it's going to compete for resources just
like anything running, but it should never cause the UI to lock unless
it's using 100% of the CPU, and in that case it's poorly designed and
would cause the problem no matter where you put it.

Running it at a lower priority would allow the UI to get quantum before
the background worker, but it wouldn't fit the flaw in what the thread
is doing, or help your battery life.

You've got something wrong in how you're either creating and using the
thread, or in what it's doing. We'd need to see code to tell you more.


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



"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
    ... 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
    ... *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
    ... "So if you change the priority of other threads in your app how will ... that the non-responsiveness is caused by running my background sync ... running on a lower priority so not to interfere with the GUI, ...
    (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)
  • Re: Background thread with lower priority
    ... Jeffry van de Vuurst ... the Priority to BelowNormal, it wouldn't get any time because the UI ... the background sync takes about 20 seconds. ...
    (microsoft.public.dotnet.framework.compactframework)