Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1363
| Date | 2013-02-16 11:00 +0100 |
|---|---|
| From | Marcel Müller <news.5.maazl@spamgourmet.org> |
| Newsgroups | comp.programming.threads |
| Subject | Re: Are detached threads useful? |
| References | <cfd2e5c1-5c00-4ebb-9da1-a3588dc41d79@w14g2000vba.googlegroups.com> |
| Message-ID | <511f58cd$0$6629$9b4e6d93@newsspool2.arcor-online.net> (permalink) |
| Organization | Arcor |
On 15.02.13 03.52, Michael Podolsky wrote: > Hello All, > > I have a general feeling that to detach a thread is a bad idea. You talk about thread that are started with a task fire and forget, aren't you. > Detaching threads allows us not to register some threads in some > containers, but that operation should be very cheep. It saves us from > long waiting on join operation... but implementing effective join > operations on a number of threads is anyway an essential task > > We pay for using detached threads by producing shaky designs (what was > ok to terminate today may be not ok tomorrow when we change some > thread functionality). > > In short, I declare "detached threads should not be used". And I would > like to hear about examples where having them is really a good (or > even necessary?) idea. In general I agree with you. I would prefer thread pools with worker and a worker queue for the tasks. This limits the used system resources and ensures a graceful shutdown of the application. But there are cases where other mechanisms are sufficient. Think of workers that automatically notify some object on task completion, and the object knows about it's pending state when the worker is started. There might be no need to know about the worker thread handle in this case. Furthermore I have programmed a platform in the 90's where a thread consumes almost no system resources. Starting a thread was in the order of 5 clock cycles. A thread switch was also in this order. Threads had no handles. All they need was a bit of memory for the stack. This could be on the stack of another thread. Blocked threads only put their last stack pointer at the semaphores or communication channels location. If the semaphore is also on the stack of the other thread and it is dismissed e.g. because of a function return, the waiting thread is implicitly destroyed too without leaving any orphaned resources behind. On this platform it was common practice to spawn threads over and over without keeping track of them. In fact it turned out to be less race condition prone despite the many threads. When you put each state machine of the application in an own thread that manages the state transitions by responding to messages on communication channels then you need almost no shared memory. Marcel
Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar
Are detached threads useful? Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-02-14 18:52 -0800
Re: Are detached threads useful? Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-02-16 11:00 +0100
Re: Are detached threads useful? andrew@cucumber.demon.co.uk (Andrew Gabriel) - 2013-03-02 15:16 +0000
Re: Are detached threads useful? Michael Podolsky <michael.podolsky.69@gmail.com> - 2013-03-07 22:27 -0800
Re: Are detached threads useful? andrew@cucumber.demon.co.uk (Andrew Gabriel) - 2013-03-18 14:57 +0000
Re: Are detached threads useful? Gerald Breuer <Gerald.Breuer@googlemail.com> - 2013-03-08 19:11 +0100
csiph-web