[concurrency-interest] Termination of daemon threads

Gregg Wonderly gregg at cytetech.com
Wed Apr 2 13:20:24 EDT 2008

Peter Kovacs wrote:
> OK, I try to put my egotism aside: may "critical" mean "something"
> which other processes rely on? Should the answer then not be: a daemon
> thread can do anything, just be prepared for it being abruptly
> terminated? Just as if the process itself would be killed -- I assume.
> So the advice goes: don't do anything critical in non-daemon threads
> either, because your process may get killed. :-)

I think it's a little bit naive to believe that anything that you software is 
doing will always complete successfully.  Stuff Happens!  A daemon thread should 
be used to do things that are not about the lifecycle of the system.  The 
lifecycle related operations should be done with non-daemon threads.  In the 
end, if you need something to happen atomically, you need transactional behavior 
that accounts for aborts of any type in the middle of the operation.  So, for 
example, if you have something like

synchronized( foo ) {
	val1 = foo.get( foo.lastIndex() ).theValue();
	val2 = foo.get( foo.firstIndex() ).theValue();

you need to understand that a RuntimeException, or Error can interrupt the 
execution of any of these statements.  For example, if an ArrayIndexOutOfBounds 
or NullPointerException occurs when computing the value for val2 then val1 may 
be changed, and val2 not.  You have to be careful in the design of this type of 

A daemon thread, would of course allow thread death to interfere with the sanity 
of this set of atomically viewed changes.  But, that would happen because of VM 
termination, so as long as none of these perform operations visible outside of 
the VM, then things are likely okay from that perspective.

Gregg Wonderly

More information about the Concurrency-interest mailing list