I have an application with several BackgroundWorker threads. I hoped I'd be
able to just type backgroundworker1.Name = "bw1"; but I don't see a name
property.

Any thoughts on how to name a backgroundworker thread?

Thanks,
Randy

Hi,

You could simply wrap the thread in a new class with a Name property:
class MyThread
{
public Thread thread;
public string Name;
}



"randy1200" <(E-Mail Removed)> wrote in message
news:385C7000-153B-427F-B35C-(E-Mail Removed)...
>I have an application with several BackgroundWorker threads. I hoped I'd be
> able to just type backgroundworker1.Name = "bw1"; but I don't see a name
> property.
>
> Any thoughts on how to name a backgroundworker thread?
>
> Thanks,
> Randy

Randy,

Unfortunately, this is not possible. The BackgroundWorker class uses a
thread from the thread pool (through a call to BeginInvoke on a delegate) to
handle the background task (which upon thinking about it, is a really bad
idea, since the background task might take a very long time to complete).
Because of this, you don't have a reference to a Thread object which you can
set the name on.

The only thing I can think of doing which would accomplish this would be
to set the name of the thread (using the static CurrentThread property) in
the callback for the BackgroundWorker, and setting the name of that thread
there.

However, this can cause an issue, because another piece of code can set
the name of the thread before you do, and that would cause an error. While
the Name property of the Thread is supposed to be write-once, it appears
that you can pass null to the Name property and it will take (I'm not sure,
you have to check). If it allows you to do that, then you can set it to
null, then set it to your name, and then set it to null again when the
background thread completes.

Of course, this is completely implementation-dependent, and I would not
recommend doing this, but it seems like it might be able to do be done.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)


"randy1200" <(E-Mail Removed)> wrote in message
news:385C7000-153B-427F-B35C-(E-Mail Removed)...
>I have an application with several BackgroundWorker threads. I hoped I'd be
> able to just type backgroundworker1.Name = "bw1"; but I don't see a name
> property.
>
> Any thoughts on how to name a backgroundworker thread?
>
> Thanks,
> Randy

"randy1200" <(E-Mail Removed)> wrote in message
news:385C7000-153B-427F-B35C-(E-Mail Removed)...
>I have an application with several BackgroundWorker threads. I hoped I'd be
> able to just type backgroundworker1.Name = "bw1"; but I don't see a name
> property.
>
> Any thoughts on how to name a backgroundworker thread?
>
> Thanks,
> Randy



And would you ever need the name of a thread taken from the pool?

Willy.

Thanks to all for the responses. The reason I wanted to set names is because
I had several background worker threads, and naming them would make debugging
easier. In addition, it seemed like it should be a trival thing to so. All
the insights are appreciated, and perhaps Microsoft will see this and make a
Name property part of the background worker thread in a future release.

Thanks again,
Randy

"Willy Denoyette [MVP]" wrote:

> "randy1200" <(E-Mail Removed)> wrote in message
> news:385C7000-153B-427F-B35C-(E-Mail Removed)...
> >I have an application with several BackgroundWorker threads. I hoped I'd be
> > able to just type backgroundworker1.Name = "bw1"; but I don't see a name
> > property.
> >
> > Any thoughts on how to name a backgroundworker thread?
> >
> > Thanks,
> > Randy
>
>
>
> And would you ever need the name of a thread taken from the pool?
>
> Willy.
>
>

"randy1200" <(E-Mail Removed)> wrote in message
news67F89C5-A2DB-4F01-9AAF-(E-Mail Removed)...
> Thanks to all for the responses. The reason I wanted to set names is
> because
> I had several background worker threads, and naming them would make
> debugging
> easier. In addition, it seemed like it should be a trival thing to so. All
> the insights are appreciated, and perhaps Microsoft will see this and make
> a
> Name property part of the background worker thread in a future release.

No, they won't, it makes no sense really, a thread from the pool is not tied
to a particular task, not even to a particular Application Domain, once your
task is done, the thread returns to the pool where it can be assigned
another task, so how it would help in debugging is not entirely clear to
me. Also, don't forget the the pool threads are used by timer delegates and
asynchronous IO delegates, how would it help in debugging, when having a
thread to appear executing an IO callback and a few moments later a timer
callback?

Willy.

Say you've got a bunch of different panels, and each panel has it's own
background worker that you've dragged out of the toolbox. This all works
great, but it takes some effort to figure out which thread goes with which
panel. It would be nice to look at the Name property in the thread window of
the debugger.

Currently, assigning a Name to a thread more than once will throw an
exception. My thought is that if Microsoft could add a mechanism to allow
name assignment when background worker grabs a thread out of the thread pool,
then remove any assigned name when the thread is returned to the pool.

During debugging, using the Debug->Windows->Threads window can be a
life-saver, and of course, this is where the names show up.




"Willy Denoyette [MVP]" wrote:

> "randy1200" <(E-Mail Removed)> wrote in message
> news67F89C5-A2DB-4F01-9AAF-(E-Mail Removed)...
> > Thanks to all for the responses. The reason I wanted to set names is
> > because
> > I had several background worker threads, and naming them would make
> > debugging
> > easier. In addition, it seemed like it should be a trival thing to so. All
> > the insights are appreciated, and perhaps Microsoft will see this and make
> > a
> > Name property part of the background worker thread in a future release.
>
> No, they won't, it makes no sense really, a thread from the pool is not tied
> to a particular task, not even to a particular Application Domain, once your
> task is done, the thread returns to the pool where it can be assigned
> another task, so how it would help in debugging is not entirely clear to
> me. Also, don't forget the the pool threads are used by timer delegates and
> asynchronous IO delegates, how would it help in debugging, when having a
> thread to appear executing an IO callback and a few moments later a timer
> callback?
>
> Willy.
>
>

"randy1200" <(E-Mail Removed)> wrote in message
news:45C4B83E-CA7C-4305-BFBE-(E-Mail Removed)...
> Say you've got a bunch of different panels, and each panel has it's own
> background worker that you've dragged out of the toolbox. This all works
> great, but it takes some effort to figure out which thread goes with which
> panel. It would be nice to look at the Name property in the thread window
> of
> the debugger.
>

Don't tell me you burn a thread for each panel on your UI, this is a sign
for a bad design, really. Some reasons not to use worker threads from the
pool:
1. Worker threads are by design initialized to enter the MTA, UI threads
NEED to run in an STA thread that pumps the windows message queue, MTA
threads don't pump the queue, not respecting this simple rule will lead to
deadlocking.
2. Each thread consumes 1MB of comitted stack space, this means that if you
have 20 panels, you are wasting 20MB of private memory. No big deal you say,
wel assume your applicaton is run on Terminal Server, by say 100 users. Here
you waste 100 X 20MB = 2GB of memory (private remember!) as stack space, bed
this customer will not be happy at all :-((
3. The number of threads in the pool are restricted (25 per process per
processor), using too many of them can easely lead to deadlocks, especially
when using them for UI related code.
4. The underlying GDI (and GDI+) code is single threaded by design, so you
won't take any performance advantage when running UI code in different
threads, to the contrary, you will incur a (small) performance hit when
doing so.

Therefore I would suggest you to use them only for short running tasks (say
a couple of seconds at most).
You rarely need to handle UI stuff in different threads, and if you really
think you need to, just use regular threads, which you can control yourself,
you can name the threads, and you can initialize them to enter a STA.


> Currently, assigning a Name to a thread more than once will throw an
> exception. My thought is that if Microsoft could add a mechanism to allow
> name assignment when background worker grabs a thread out of the thread
> pool,
> then remove any assigned name when the thread is returned to the pool.
>

But that's exactly the point , a thread in the pool (really an OS thread)
is created once, it stays in the pool once created, you can't change the
name of a thread you can only name a thread when he gets created. You
don't want the thread to return to the OS and make the CLR to recreate the
thread just because you want it to give a name do you? this would completely
defeat the purpose of the pool.


> During debugging, using the Debug->Windows->Threads window can be a
> life-saver, and of course, this is where the names show up.

No, what they should do is display the managed thread ID next to the (OS)
thread ID, note that this is something you can do yourself in the Immediate
window , just type:
? Thread.CurrentThread.ManagedThreadId
and you'll get the managed thread Id back, just write it down .

Willy.



Willy.

I oversimplified so as not to distract from the actual question. I have a
base class with background worker. Each child class takes an instance of this
for each panel.

The background worker threads are doing exactly what they are intended to
do, which is perform a background task asynchronously, allowing immediate
return of the foreground thread to the UI. That’s pretty much Computer
Science 101.

Going to a thread pool is inefficient, as it takes more time to create a
thread pool class than it does to simply drag the background worker out of
the toolbox. The advantages of the thread pool are not significant for this
type of usage.

With a little imagination, I believe Microsoft could provide a mechanism for
changing names of threads being used and released by a mechanism like
background worker. The world won’t stop turning if background worker objects
never get a Name property, but it would be nice.

Randy


"Willy Denoyette [MVP]" wrote:

> "randy1200" <(E-Mail Removed)> wrote in message
> news:45C4B83E-CA7C-4305-BFBE-(E-Mail Removed)...
> > Say you've got a bunch of different panels, and each panel has it's own
> > background worker that you've dragged out of the toolbox. This all works
> > great, but it takes some effort to figure out which thread goes with which
> > panel. It would be nice to look at the Name property in the thread window
> > of
> > the debugger.
> >
>
> Don't tell me you burn a thread for each panel on your UI, this is a sign
> for a bad design, really. Some reasons not to use worker threads from the
> pool:
> 1. Worker threads are by design initialized to enter the MTA, UI threads
> NEED to run in an STA thread that pumps the windows message queue, MTA
> threads don't pump the queue, not respecting this simple rule will lead to
> deadlocking.
> 2. Each thread consumes 1MB of comitted stack space, this means that if you
> have 20 panels, you are wasting 20MB of private memory. No big deal you say,
> wel assume your applicaton is run on Terminal Server, by say 100 users. Here
> you waste 100 X 20MB = 2GB of memory (private remember!) as stack space, bed
> this customer will not be happy at all :-((
> 3. The number of threads in the pool are restricted (25 per process per
> processor), using too many of them can easely lead to deadlocks, especially
> when using them for UI related code.
> 4. The underlying GDI (and GDI+) code is single threaded by design, so you
> won't take any performance advantage when running UI code in different
> threads, to the contrary, you will incur a (small) performance hit when
> doing so.
>
> Therefore I would suggest you to use them only for short running tasks (say
> a couple of seconds at most).
> You rarely need to handle UI stuff in different threads, and if you really
> think you need to, just use regular threads, which you can control yourself,
> you can name the threads, and you can initialize them to enter a STA.
>
>
> > Currently, assigning a Name to a thread more than once will throw an
> > exception. My thought is that if Microsoft could add a mechanism to allow
> > name assignment when background worker grabs a thread out of the thread
> > pool,
> > then remove any assigned name when the thread is returned to the pool.
> >
>
> But that's exactly the point , a thread in the pool (really an OS thread)
> is created once, it stays in the pool once created, you can't change the
> name of a thread you can only name a thread when he gets created. You
> don't want the thread to return to the OS and make the CLR to recreate the
> thread just because you want it to give a name do you? this would completely
> defeat the purpose of the pool.
>
>
> > During debugging, using the Debug->Windows->Threads window can be a
> > life-saver, and of course, this is where the names show up.
>
> No, what they should do is display the managed thread ID next to the (OS)
> thread ID, note that this is something you can do yourself in the Immediate
> window , just type:
> ? Thread.CurrentThread.ManagedThreadId
> and you'll get the managed thread Id back, just write it down .
>
> Willy.
>
>
>
> Willy.
>

[abascalufe]

Originally Posted by =?Utf-8?B?cmFuZHkxMjAw?=

I have an application with several BackgroundWorker threads. I hoped I'd be
able to just type backgroundworker1.Name = "bw1"; but I don't see a name
property.

Any thoughts on how to name a backgroundworker thread?

Thanks,
Randy

ojala te sirva

if (Thread.CurrentThread.Name == null)
Thread.CurrentThread.Name = "MyBackgroundWorkerThread";