Talk:Thread safety

From Wikipedia, the free encyclopedia

[edit] Layout

This article needs to be a little clear formatted to allow easy dissemination of what it saying. Falls End (T, C) 00:36, 1 December 2005 (UTC)

I've rewikfied a bit. I have removed this phrase from the intro, as it's a repeat of what is found in the (new) section 'Achieving thread safety'. "Common ways of creating thread-safe code include writing reentrant code, using Thread-local storage to localize data to each thread, guarding shared data with mutual exclusion so that only one thread uses it at a time, and modifying shared data with atomic operations." In a longer article it's probably worth keeping this repetition, but I don't think it's justified yet.

What do you think of my changes? :) --Stevage 02:57, 1 December 2005 (UTC)

[edit] Page move

I think this article should be renamed to 'Thread safety'. Can anyone work out how to do it? Jimbletang 03:05, 8 December 2006 (UTC)

I thought the same thing, so I moved it. - furrykef (Talk at me) 00:58, 17 June 2007 (UTC)

[edit] Reentrancy does not always imply thread-safety

I think the article is wrong when it infers that reentrancy is a sufficient condition to ensure thread safety. It's not, and the two concepts of thread safety and reentrancy are distinct. It's true that reentrant functions are often thread-safe too, but it's easy to construct examples of reentrant functions that are not thread-safe.

So, I think it would be better to eliminate phrases like "A subroutine is reentrant, and thus thread-safe ..." because they give incorrect impressions that reentrancy is some sort of a stronger guarantee of thread-safety.