Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #1363

Re: Are detached threads useful?

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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