| Groups | Blog | Home |
dotnet general : are objects assosiated with the thread they are created on?
Are objects implicitly stored in the TLS of the currently running thread?
When creating multithreaded applications i get errors when accessing data from a different thread than the thread used to create the objects (which is easely fixed by calling Invoke()). Also, is there a way to acces the thread which created the thread, or in other words: is there a parent/child
[quoted text, click to view]
MariusI wrote: > Are objects implicitly stored in the TLS of the currently running > thread? When creating multithreaded applications i get errors when > accessing data from a different thread than the thread used to create > the objects (which is easely fixed by calling Invoke()). Also, is > there a way to acces the thread which created the thread, or in other > words: is there a parent/child relationship between threads? threads are just run contexts in the same code. You've to understand a couple things: - variables created in a routine's scope (i.e local scope) are created in the stack frame of the caller. This means that every thread calling a method Foo and Foo creates a local variable bar will have its own bar instance, not sharing it with any other thread. - variables created in a program scope (or lets say appDomain scope), or better: in the scope that contains the thread spawn code, are shared among threads as these aren't created in the stackframe of the thread, because they're not locally created. So if you have a class member variable _bar and you create that in a method Foo, calling the method Foo with multiple threads will make every thread access the same class member variable _bar. Objects aren't 'associated' with a thread normally, unless as said they're created locally in a method scope. There's one exception: Windows UI resources. By design, the windows UI is single threaded. It internally associates resources to a single thread, namely the calling thread. This means that if you create a button in thread A, the HWND (and other resources, or better: Handles) are associated with A. If you then want to do something with the button created by A from thread B, you have to do that through A, via Invoke, because B doesn't 'own' the handles of the button. Everyone who has done some win32 programming knows that if you request the HDC for a window from different threads, you'll get different values, and each thread has to use their own HDC, not another thread's one. Not all applications play nice. You can see that in action when some application runs and an icon changes in explorer, or leaks memory (tiny). So rules of thumb: 1) locally created variables in methods are local to a thread, every thread has its own versions 2) globally created variables are global to every thread: all threads share the same version 3) Windows UI resources are associated to the calling thread and you should use Invoke to use them, even though you use them in a scenario where 2) would be true. (example: you have a worker thread which wants to update a progress bar in a form on the main thread. You can but don't do that directly, use invoke. FB -- ------------------------------------------------------------------------ Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#)
Thank you, this explains things to a great deal, but my second question
remains unanswered: "Also, is there a way to acces the thread which created the thread, or in other words: is there a parent/child relationship between threads?" [quoted text, click to view] "Frans Bouma [C# MVP]" wrote:
> MariusI wrote: > > > Are objects implicitly stored in the TLS of the currently running > > thread? When creating multithreaded applications i get errors when > > accessing data from a different thread than the thread used to create > > the objects (which is easely fixed by calling Invoke()). Also, is > > there a way to acces the thread which created the thread, or in other > > words: is there a parent/child relationship between threads? > > threads are just run contexts in the same code. You've to understand a > couple things: > - variables created in a routine's scope (i.e local scope) are created > in the stack frame of the caller. This means that every thread calling > a method Foo and Foo creates a local variable bar will have its own bar > instance, not sharing it with any other thread. > - variables created in a program scope (or lets say appDomain scope), > or better: in the scope that contains the thread spawn code, are shared > among threads as these aren't created in the stackframe of the thread, > because they're not locally created. > > So if you have a class member variable _bar and you create that in a > method Foo, calling the method Foo with multiple threads will make > every thread access the same class member variable _bar. > > Objects aren't 'associated' with a thread normally, unless as said > they're created locally in a method scope. There's one exception: > Windows UI resources. > > By design, the windows UI is single threaded. It internally associates > resources to a single thread, namely the calling thread. This means > that if you create a button in thread A, the HWND (and other resources, > or better: Handles) are associated with A. If you then want to do > something with the button created by A from thread B, you have to do > that through A, via Invoke, because B doesn't 'own' the handles of the > button. Everyone who has done some win32 programming knows that if you > request the HDC for a window from different threads, you'll get > different values, and each thread has to use their own HDC, not another > thread's one. > > Not all applications play nice. You can see that in action when some > application runs and an icon changes in explorer, or leaks memory > (tiny). > > So rules of thumb: > 1) locally created variables in methods are local to a thread, every > thread has its own versions > 2) globally created variables are global to every thread: all threads > share the same version > 3) Windows UI resources are associated to the calling thread and you > should use Invoke to use them, even though you use them in a scenario > where 2) would be true. (example: you have a worker thread which wants > to update a progress bar in a form on the main thread. You can but > don't do that directly, use invoke. > > FB > > -- > ------------------------------------------------------------------------ > Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com > My .NET blog: http://weblogs.asp.net/fbouma > Microsoft MVP (C#) > ------------------------------------------------------------------------
[quoted text, click to view]
MariusI <MariusI@discussions.microsoft.com> wrote: > Thank you, this explains things to a great deal, but my second question > remains unanswered: "Also, is there a way to acces the thread which created > the thread, or in other words: is there a parent/child relationship between > threads?" Not that I'm aware of, and not that the .NET API exposes. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
MariusI wrote: > Thank you, this explains things to a great deal, but my second > question remains unanswered: "Also, is there a way to acces the > thread which created the thread, or in other words: is there a > parent/child relationship between threads?" No. A thread is a thread, in a process, all threads are equal. Some will qualify one thread as the 'main' thread and see the other threads as 'worker threads' but technically they're the same. FB [quoted text, click to view] > > "Frans Bouma [C# MVP]" wrote: > > > MariusI wrote: > > > > > Are objects implicitly stored in the TLS of the currently running > > > thread? When creating multithreaded applications i get errors > > > when accessing data from a different thread than the thread used > > > to create the objects (which is easely fixed by calling > > > Invoke()). Also, is there a way to acces the thread which created > > > the thread, or in other words: is there a parent/child > > > relationship between threads? > > > > threads are just run contexts in the same code. You've to > > understand a couple things: > > - variables created in a routine's scope (i.e local scope) are > > created in the stack frame of the caller. This means that every > > thread calling a method Foo and Foo creates a local variable bar > > will have its own bar instance, not sharing it with any other > > thread. - variables created in a program scope (or lets say > > appDomain scope), or better: in the scope that contains the thread > > spawn code, are shared among threads as these aren't created in the > > stackframe of the thread, because they're not locally created. > > > > So if you have a class member variable _bar and you create that in > > a method Foo, calling the method Foo with multiple threads will make > > every thread access the same class member variable _bar. > > > > Objects aren't 'associated' with a thread normally, unless as said > > they're created locally in a method scope. There's one exception: > > Windows UI resources. > > > > By design, the windows UI is single threaded. It internally > > associates resources to a single thread, namely the calling thread. > > This means that if you create a button in thread A, the HWND (and > > other resources, or better: Handles) are associated with A. If you > > then want to do something with the button created by A from thread > > B, you have to do that through A, via Invoke, because B doesn't > > 'own' the handles of the button. Everyone who has done some win32 > > programming knows that if you request the HDC for a window from > > different threads, you'll get different values, and each thread has > > to use their own HDC, not another thread's one. > > > > Not all applications play nice. You can see that in action when > > some application runs and an icon changes in explorer, or leaks > > memory (tiny). > > > > So rules of thumb: > > 1) locally created variables in methods are local to a thread, every > > thread has its own versions > > 2) globally created variables are global to every thread: all > > threads share the same version > > 3) Windows UI resources are associated to the calling thread and you > > should use Invoke to use them, even though you use them in a > > scenario where 2) would be true. (example: you have a worker thread > > which wants to update a progress bar in a form on the main thread. > > You can but don't do that directly, use invoke. -- ------------------------------------------------------------------------ Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#)
[quoted text, click to view]
Frans Bouma [C# MVP] <perseus.usenetNOSPAM@xs4all.nl> wrote: > > Thank you, this explains things to a great deal, but my second > > question remains unanswered: "Also, is there a way to acces the > > thread which created the thread, or in other words: is there a > > parent/child relationship between threads?" > > No. A thread is a thread, in a process, all threads are equal. Some > will qualify one thread as the 'main' thread and see the other threads > as 'worker threads' but technically they're the same. One slight difference - you can't make the "main" thread a background thread (or at least, it doesn't have any effect). For instance: using System; using System.Threading; public class Test { static void Main(string[] args) { Thread t = new Thread (new ThreadStart(KeepCounting)); t.IsBackground = true; t.Start(); t.IsBackground = true; // The process should immediately finish now... Thread.Sleep(10000); } static void KeepCounting() { int i=0; while (true) { Console.WriteLine (i++); Thread.Sleep(1000); } } } -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
Jon Skeet [C# MVP] wrote: > Frans Bouma [C# MVP] <perseus.usenetNOSPAM@xs4all.nl> wrote: > > > Thank you, this explains things to a great deal, but my second > > > question remains unanswered: "Also, is there a way to acces the > > > thread which created the thread, or in other words: is there a > > > parent/child relationship between threads?" > > > > No. A thread is a thread, in a process, all threads are equal. Some > > will qualify one thread as the 'main' thread and see the other > > threads as 'worker threads' but technically they're the same. > > One slight difference - you can't make the "main" thread a background > thread (or at least, it doesn't have any effect). For instance: > > using System; > using System.Threading; > > public class Test > { > static void Main(string[] args) > { > Thread t = new Thread (new ThreadStart(KeepCounting)); > t.IsBackground = true; > t.Start(); > t.IsBackground = true; > // The process should immediately finish now... > Thread.Sleep(10000); > } > > static void KeepCounting() > { > int i=0; > while (true) > { > Console.WriteLine (i++); > Thread.Sleep(1000); > } > } > } Ok, but the 'main' thread isn't a higher-order thread than the thread you created, at least not for the system it runs on. Windows schedules threads, based on their priority. So unless you kick the mainthread's priority, it won't be a 'higher order' thread of some kind, which was what I argued. That's the technical side of things. Semantically, it's another story of course, as you there have a 'main' thread and 'worker' threads, which act as if there's some kind of ranking system in place ;) FB -- ------------------------------------------------------------------------ Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#)
[quoted text, click to view]
Frans Bouma [C# MVP] <perseus.usenetNOSPAM@xs4all.nl> wrote: > Ok, but the 'main' thread isn't a higher-order thread than the thread > you created, at least not for the system it runs on. Windows schedules > threads, based on their priority. So unless you kick the mainthread's > priority, it won't be a 'higher order' thread of some kind, which was > what I argued. Indeed. [quoted text, click to view] > That's the technical side of things. Semantically, it's another story > of course, as you there have a 'main' thread and 'worker' threads, > which act as if there's some kind of ranking system in place ;) Sort of - of course, there's nothing to say that the thread that starts off in Main has to be the UI "main" thread, etc :) -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
| home · blog · groups | Questions? Comments? Contact the dn |