Talk:Thread (computing)

Template:Vital article

Untitled

Thanks for fleshing out the stub, Lee. I knew this stuff, but it wasn't on the tip of my tongue (one step further buried in the memory banks). User:Ed Poor

Renaming

Just for note. I renamed the article to thread (computer science) because threading not necessarily only in software enginnering. -- Taku 16:14, Mar 28, 2004 (UTC)

Process creation cost

From the article:

"Systems like Windows NT, OS/2 and Linux (2.5 kernel or higher) are said to have "cheap" threads and "expensive" processes, while in other systems there is not so big a difference."

Eh? I though one major advantage of Linux was its relatively low process creation cost, and the new NPTL implementation of Linux threads is a 1:1 implementation where there is little difference between a thread and a process at the lowest level. -- The Anome 22:33, 22 Oct 2004 (UTC)

If you take a look at NetBSD 2.x or DragonFly BSD you will notice that they don't use 1:1, but instead N:M, which is a lot more efficient than Linux 1:1. I've added a link about NetBSD SA (Scheduler Activations) in this page that I advise you to look at. -- RuiPaulo 23:54, 24 Oct 2004 (UTC)

Authors

The section titled "Processes, Threads, and Fibers" and its subsections were started by Daniel Barbalace.

Website: http://www.clearthought.info

Thanks for the excellent work, Daniel. -- The Anome 14:59, 24 Oct 2004 (UTC)

System call for a context switch?

The article says "Typically fibers are implemented entirely in userspace. As a result, context switching between fibers in a process is extremely efficient: because the kernel is oblivious to the existence of fibers, a context switch does not require a system call." Why would a context switch require a system call in any situation? Is it talking about non-preemptive multitasking? If so, wouldn't it be better if the article mentioned it? If the article isn't intended to say that a system call is required for a context switch, then it would be better if it were cleared up in the article. It's misleading. It would help if the article (that section) is clearer anyway.

Yeah, it would be more clear to say "a context switch does not require a kernel entry" or some such. I'm not sure that it matters whether or not the thread implementation is preemptively scheduled or not: in a cooperatively scheduled implementation of kernel threads, there is still some kernel state associated with the currently-running thread, and so a kernel entry is some kind is required to switch that state, right? The point is somewhat academic, anyway, as cooperatively-scheduled kernel thread implementations are rare AFAIK. Neilc 04:23, 20 Jun 2005 (UTC)

I made that change. I was trying to figure out how to get something about pre-emptive scheduling of threads involving the kernel programming a hardware interrupt in order to stop the current thread, but couldn't figure out how to word that decently. :) Dianne Hackborn 05:51, 22 Jun 2005 (UTC)

Multiprocess vs. Multithreaded vs. Fibers

Would anyone mind if I did some cleanup of this table? It seems to me that all the long discussion about particular systems (especially the big one on AmigaOS) hides the comparison it is trying to make. What about moving discussion about specific operating systems to a section below?

Also, I kind-of disagree with the definition of multiprocess that is being implied here -- that it means something about more than one user-level "application" running. I think it should be much more tied to the idea of memory protection: that is, an OS with memory protection has multiple processes. From this perspective, for example, the traditional AmigaOS (pre-PPC) would be better classified as multi-threaded only, and would serve as a good example to illustrate the difference between that and processes.

Anyway, I don't want to step on anyone's toes. :)

Dianne Hackborn

Sounds good to me. Be bold! :) Neilc 05:00, 20 Jun 2005 (UTC)

Also, I want to say that the text in the table is really hard to read; not everyone has a big display. -- Taku 05:59, Jun 20, 2005 (UTC)

Books

I've added Three .NET threading resources - two of these are admittedly my own published works. I've added them only because there were no other .NET programming resources listed. Feel free to remove them if you feel they are inappropriate. Both of these books are out of print but you can still find them quite often at book stores and from secondary book stores. I have a fourth book published that is still on the market that I didn't list because it covers two other areas as well as threading. The title is Pro .Net 1. 1 Remoting, Reflection, and Threading and the ISBN is 1-590-59452-5. While it is more "current", the fact that it covers two other topics doesn't seem to make it appropriate for this article. Once again, feel free to add it if you feel otherwise. - Sleepnomore 15:46, August 26, 2005 (UTC)

Fibers and NPOV

Yeah, this whole Fiber stuff needs rewriting, the term is not used for much outside of the NTcentric world. Also curious is the table. What the hell is the last entry? It says most OSs since 1995 use a proces/thread/fiber model. But above it, it says that OS X Win 2k etc (Major OSes released AFTER 1995) use a process/thread model. What came in 1995? Win95?? What about NT (released 93) or Macs which were stuck with classic MacOS (system 7, I believe) until OSX. Seems a little Windowscentric. So much for NPOV! —The preceding unsigned comment was added by 58.107.87.183 (talk • contribs) 23:37, 15 June 2006 (UTC1)

This edit got rid of the "Comparison between models" section, including the offending table.

The next-to-last entry said "Although each of these operating systems allows the programmer to implement fibers or use a fiber library, most programmers do not use fibers in their applications." So, yeah, in most OSes released after 1995, you could write your own fiber package and use it, but I don't know what OSes other than Windows NT provided any support for even third-party fiber packages. Guy Harris (talk) 22:39, 19 June 2018 (UTC)

Threads vs Tasks

"IBM PL/I(F) included support for multithreading (called multitasking) in the late 1960s" - okay, I was around when there were no threads. It was called multi-tasking because, well, they were called tasks. The term remains with us -- one multitasks by doing multiple things. My issue is not with the change in the phrase (we do that all the time), it's that throughout this document it is "tasks" or "(called multitasking)" or "in which context they were called 'tasks'." I suggest that a section titled something like "The Change from Task or Process to Thread" and the reasoning for it (with docs). Otherwise it just seems like someone one day started calling it threads without rhyme or reason. Cheers. Lloydsargent (talk) —Preceding undated comment added 22:27, 19 June 2018 (UTC)