Talk:Thread (computing)/Archive 1
Page contents not supported in other languages.
Archive 1 |
Not always are processes provided only by operating system. Erlang programming language has support for processes in language - they are completely isolated from one another (while running within single OS process). Pavel Vozenilek 22:02, 29 July 2005 (UTC)
Many web servers use threads somehow, sure. However, I find those two paragraphs not very useful. In my opinion, it gives the wrong idea that either multi-threading or multi-processing is necessary for web servers and similar kind of servers in general. That's far from the truth. At least on single-CPU machines an approach using select, poll, kevent, epoll etc. is usually far more efficient and also a fairly popular approach for all kinds of servers at least in C/C++. Even in Java using tons of threads does not seem to scale very well and using non-blocking I/O instead is actually better even if the naive approach of one thread per connection - or in C/C++ even one process per connection (resp. client) - is easier to code.
The part about Apache 1.3 using multi-processing almost qualifies as FUD. At the very least a lot of context or explanations are missing and most of those "dangers" apply to multi-threading equivalently. In short, I think the article was better without those two paragraphs. --82.141.49.144 05:14, 4 December 2005 (UTC)
"""while in other operating systems there is not so big a difference"""
The concept of a process, thread, and fiber are interrelated by a sense of "ownership" and of containment. .... A fiber can be scheduled to run in any thread in the same process.
There seems a contradiction. If a fiber can be run in any thread, then it's not cointained within any specific thread, nor owned by any specific thread. --tyomitch 15:25, 8 May 2006 (UTC)
For context enrichment, could be nice to add some thread history (OS related, but makes sense also into this context). --User:faragon12:52, 7 Jun 2006 (GMT+1)
A while ago I changed the example to a C# example that I believed showed purely the concept of multi-threading more clearly than our current example which would be more suited to Algorithms For Prime Number Generation ;) I just feel that the example should be very closely tied to threading as opposed to having an exterior purpose. Here is the reverted example I propsed before: [2] Any thoughts? Martin Hinks 17:43, 29 January 2006 (UTC)
The commentary pertaining to the example says, "of course, this problem [the race condition] is easily corrected using standard programming techniques" raises the question: How?68.50.203.109 04:17, 9 July 2006 (UTC)
Ey people, i'm kind of a newbie to CPU's. The terminology used in this article (and most wikipedia articles) is kind of complex. So, i'm wondering if someone can tell me a little about it in plain english like;
1) What exactly are Threads, what do they do, and how do they work?
2) What is the difference between a thread, process, and the other thing?
3) What exactly does a kernel do? Is it embedded in an Operating System? Why 'Linux Kernel' and not just 'Linux'?
4) Tell me some other things i should know about this stuff please.
Any help would be greatly appreciated and if you do help me, ill make it worth a lot of other people's time by editing this main article into simpler words. Thanks.KittenKiller
It seems to me that the terminology used in most computer science wikipedia articles is kind of complex. However, the same cannot be said for most wikipedia articles. Care to comment?68.50.203.109 04:21, 9 July 2006 (UTC)
Personally I like the old table format more -- the new format is too compact and is difficult to read. Neilc 00:48, 23 Jun 2005 (UTC)
I don't see around here (The referenced talk page) who added the {{contradict}} tag, and more to the point, why? 68.39.174.238 03:40, 18 July 2006 (UTC)
Forgive me if this is a poorly stated ... I'm rather tired. I think a good restucturing would go a long way to improving this article. The section headers are also inapropriate in some places were the discussion strays from what the section header talks about. In general, I think there should be sections comparing (or at least saying a small amount before linking to another article) the entire spectrum of: (1) implementation: kernel-space vs. user-space, (2) for kernel space, the model for interfacing kernel-threads and user-threads: many-to-one, one-to-one, one-to-many, (3) co-operitve scheduling (i.e. by the process) vs. premptive sceduling (i.e. by the kernel) and showing how the desireable properties of threads, namely continuing to execute the process in the face of blocking calls and being able to run on multiprocessor machines, pretty much follow directly from these three things. The article mentions most of this stuff, but the flow and cohesiveness is pretty poor.--NotQuiteEXPComplete 06:46, 9 August 2006 (UTC)
I don't think "green threads" came from SunOS. Instead, I think they camefrom the Green project:
http://today.java.net/jag/old/green
http://www.jguru.com/faq/view.jsp?EID=416246
Calling user-level threads "green threads" probably resulted from the earlyJava JDK using that name for the thread implementation inherited from theGreen project.
Booskunk 06:53, 23 October 2006 (UTC)
Some sentences in the introduction do not seem to make grammatical sense:
"On a multiprocessor or multi-core system, which are beginning into general use, threading can be achieved via multiprocessing, wherein different threads and processes can run literally simultaneously on different processors or cores."
Should be replaced with something like "which are beginning to see general use"
Also "Absent that, programs can still implement threading by using timer..." is wrong.155.232.128.10 11:27, 23 January 2007 (UTC)
Can someone please provide an example in C? --Pradeep.v 06:43, 7 April 2007 (UTC)
Can someone add an explanation for 1×1, M×N, 1×M or 1:1, M:N, 1:M or whatever... —The preceding unsigned comment was added by Frap (talk • contribs) 21:26, 26 April 2007 (UTC).
Someone please address the issue of multithreaded programming in dual vs quad+ cores. Nowhere does it talk about whether or not it is more difficult for the programmer to create a program to take advantage of >2 processors. We understand from the article that you must write the application with multiple threads in mind BUT nowhere does it talk about the issue of programming difficulty or lake thereof for >2 processors.
Basically: Will a multithreaded program of today have to be modified for a computer with 4, 8, 32 cpus?
—The preceding unsigned comment was added by 64.233.242.55 (talk • contribs) 10:54, 8 November 2006 (UTC)
Para 2 starts "Multiple threads can be executed in parallel on many computer systems."
I believe you mean this in the sense of:On many computer systems, multiple threads can be executed in parallel on a single processor.
and are not refering to multiprocessing. However the existing sentence can be read either way. —Preceding unsigned comment added by 209.157.48.1 (talk) 23:19, 26 March 2008 (UTC)
Huh? Well, I'm no thread expert but I've never heard this term in this context before. Furthermore, it's spread all over the article, so one would think it's something widely known and used. However, when I search on the web, all I find is that it seems to be some seemingly unpopular concept used by Windows NT. It seems to be what I'd call user-level (or userland) threads e.g. GNU Pth or maybe it refers to anything thread-alike as used in programs with a main-loop which delegates/schedules short-lived tasks using state machines? So is "fiber" common terminology or just some marketing resp. product-specific term? --82.141.49.144 05:01, 4 December 2005 (UTC)
Thread join, which is wiki-linked from some other synchronization articles, redirects to this article, but the article never mentions joining threads. I think it would be useful to have an explanation of that technique -- it would certainly have helped me. Npdoty (talk) 03:10, 29 April 2010 (UTC)
Recently there were attempts to insert sample of "how to create thread in Java" into this article. Personally, I don't think it belongs to this article (if providing only a sample of creating thread, and only in Java, it is pretty much useless for the article, and if going into all thread-related functions for all languages/OSs, it will become unmanageable), and also it is IMHO a borderline WP:NOTHOWTO, so I've removed the sample, but if there are arguments for including such samples - let's discuss them. If it would be an article about a feature of the programming language - it would be a different story, but for features which can be adequately explained without referring to specifics of the language - IMHO it is unnecessary to introduce such samples. Ipsign (talk) 07:27, 14 September 2011 (UTC)
Daemon threads are not mentioned in the article.--Wisamzaqoot (talk) 22:49, 8 October 2011 (UTC)
"Fibers are an even lighter unit of scheduling which are cooperatively scheduled: a running fiber must explicitly "yield" to allow another fiber to run"
Ok.
"which makes their implementation much easier than kernel or user threads"
This is a little ambiguous to me. By reading the rest of the section I undestand that it means that it is easier for the OS to implement fibers when compared to threads. But at first I thought it meant that it was easier for the application programmer to use fibers instead of threads, which is not true. Threads are easier because you don't have to worry about scheduling.
"A fiber can be scheduled to run in any thread in the same process."
I don't think so. A fiber can only be scheduled to run in the thread that created it. You can however switch to a fiber that was created by a different thread, but still the fiber will run in the thread that created it.
"This permits applications to gain performance improvements by managing scheduling themselves, instead of relying on the kernel scheduler (which may not be tuned for the application)."
How can you get performance improvement by using fibers? Fibers can't run concurrently (unless they are fibers from different threads). If a fiber makes a blocking call, it won't be able to switch to another fiber until the call unblocks. If you have a single process and thread, just adding fibers won't improve performance.
"Parallel programming environments such as OpenMP typically implement their tasks through fibers."
OpenMP uses fibers? It must also use threads/processes or it wouldn't be able to use multiple processors/cores. Citation, please.
Check this out:
http://msdn.microsoft.com/en-us/library/aa915371.aspx
"In general, fibers do not provide advantages over a well-designed multithreaded application."
"From a system standpoint, a fiber assumes the identity of the thread that created it. For example, if a fiber accesses thread local storage (TLS), it is accessing the TLS of the thread that created it. In addition, if a fiber calls the ExitThread function, the thread that created it exits."
"You can call SwitchToFiber with the address of a fiber created by a different thread. To do this, you must have the address returned to the other thread when it called CreateFiber and you must use proper synchronization."
Italo Tasso (talk) 10:42, 9 January 2010 (UTC)
I agree. Fibers alone simply do not run in parallel and OpenMP is intended to exploit parallel systems. Intel is a prominent contributor/supported of the OpenMP project and a paragraph on this Intel page seems to cast further doubt on the connection: "In the Win32 threading API, there is a threading option called fibers that enables users to write their own thread scheduler and so exert fine-grained control over threading operations. This too is not possible in OpenMP."
JohnMcF (talk) 17:46, 11 February 2012 (UTC)
The text mentions an analogy, namely:
To give an analogy, multiple threads in a process are like multiple cooks reading off the same cook book and following its instructions, not necessarily from the same page.
Would the next one be better to clarify the differences between multithreading and multitasking?
To give an analogy, multiple threads in a process are like multiple cooks reading off the same cook book, sharing their ingredients and following its instructions (not necessarily from the same page). Multitasking would be multiple cooks reading off their own cook book and each one has with its own ingredients.
What do you think? --Mattias.Campe (talk) 11:21, 16 April 2012 (UTC)
In the article "Thread (computing)" - http://en.wikipedia.org/wiki/Thread_%28computing%29
There may be a word missing. Reference the third paragraph from the top...
Original...Many modern operating systems directly support both time-sliced and multiprocessor threading with a process scheduler. The kernel of an operating system allows programmers to manipulate threads via the system call interface. Some implementations are called a kernel thread, whereas a lightweight process (LWP) is a specific type of kernel thread that shares the same state and information. (This last sentence does not make sense. "... shares the same and information with what?")
Looks like the last fragment (quotation), which may actually be an editorial comment, is missing the word "state" after the word "same". It also mistakenly ends the quotation after "with what" which is NOT part of the original statement.184.36.175.67 (talk) 15:00, 5 September 2012 (UTC)
substitute "the smallest" with "a"confidence level 5/10 — Preceding unsigned comment added by 97.117.5.49 (talk) 04:15, 29 April 2013 (UTC)
As a reader, a history section would be useful here. Who first proposed the concept? Who first implemented it? — Preceding unsigned comment added by 101.109.245.117 (talk) 06:48, 17 November 2011 (UTC)
Could somebody with expertise clarify/elaborate this final part? It's not clear to me in this context what application-level event-driven programming and hardware description languages like Verilog have to do with threading in general, or with each other.
Skwuent (talk) 01:33, 13 August 2014 (UTC)
The article Thread (computer science) is a stub and does not contain any information that cannot be found in Thread (computing). I suggest doing away with the stub and just having it redirect here instead. If anyone believes that the wording of the stub article is superior to or provides additional insight to topics in this article, then the articles can be merged with a redirect. 18:33, 12 November 2014 (UTC)
Recent edits (diff) have introduced "hardware threads" into the lead. The text is not correct as it suggests hardware is involved in the topic of this article (well, it is involved, but the threading mentioned here can be performed on a very simple CPU from the 1970s—tricky hardware is not involved). I would have reverted the changes but there is also a bunch of bullet points for advantages and drawbacks that need thought. Thoughts? Johnuniq (talk) 07:31, 5 September 2014 (UTC)
This is a great article. I only wish someone could add the origin of the thread model. Like what year did it first arrive, who developed it, etc. Anyway very nice article. — Preceding unsigned comment added by Overhere2000 (talk • contribs) 22:42, 26 August 2015 (UTC)
I believe the definition of "single-threading" provided in this article is incorrect.It reads:
"In computer programming, single-threading is the processing of one command at a time.[3]"
1. It's citation is from a book about CICS programming, not programming in general. That is not such a great source for something about computing in general, but that's not really my point.
2. Computers do not process commands. Computers, if you want to use the word computers (as opposed to CPU), process instructions. A "command" is a statement in a high-level language that is meant to indicate an action to be performed. (yes, I didn't spend all day on that definition!) An interpretter or compiler transforms commands into a set of machine instructions. These are what the computer processes.
A computer will not necessarily process all the code of a single "command" at once. (1) It can't recognize what parts of the machine code are which commands from the high-level language. (2) In multi-tasking a process may be swapped out (correct me if I'm wrong) at almost any given instruction.
I have no sources to cite for this.
thank you Joe Petree — Preceding unsigned comment added by Jsp314159 (talk • contribs) 15:21, 11 February 2018 (UTC)
"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)
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)
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. :)
"Parallel programming environments such as OpenMP typically implement their tasks through fibers"Doing a github search for a popular openmp implementation (I understand there are multiple implementations) shows that there are no fibers in the implementation. But it does have pthreads. So, this statement is false, at least for using the word typically.--Resonant cacophony (talk) 06:04, 19 December 2018 (UTC)
Could you explain what category MS Windows Services fit into this? I've seen descriptions of Windows services as "processes" themselves.
I take it that in Windows Task Manager, what are described as "Services" are actually processes in general computing lexicon, and Task Manager's "Processes" are ?super-processes or programs. "Threads" as such are not displayed in Task Manager (understandably - a too low level of detail outside of technical work/debugging).
If I'm wrong about this, then I'm clearly more confused than I thought! — Preceding unsigned comment added by 80.189.81.20 (talk) 13:11, 3 July 2019 (UTC)
A service program contains executable code for one or more services. A service program created with the type SERVICE_WIN32_OWN_PROCESS contains the code for only one service. A service program created with the type SERVICE_WIN32_SHARE_PROCESS contains code for more than one service, enabling them to share code. An example of a service program that does this is the generic service host process, Svchost.exe, which hosts internal Windows services. Note that Svchost.exe is reserved for use by the operating system and should not be used by non-Windows services. Instead, developers should implement their own service hosting programs.
A service runs as a background process that can affect system performance, responsiveness, energy efficiency, and security.
In Thread (computing)#M:N (hybrid threading), somebody asked for a citation in this edit, with the reason being that "no kernel modifications are needed".
I changed that to a request for clarification, because that section says
M:N maps some M number of application threads onto some N number of kernel entities, or "virtual processors."
and, if your kernel has no such kernel entities that can be used, clearly implementing M:N threading will require kernel changes. However, if, for example, it already has such entities - perhaps using them for 1:1 threading - it may be possible to implement M:N threading on top of those entities, with only changes to the userland threading library.
So, if the discussions of the various threading models, the implementation complexity refers to the complexity of implementing the threading model atop a system with no support for threading, whether in the kernel or in userland, M:N threading involves changes in both cases, whereas 1:1 would require kernel changes but would probably only require relatively simple userland changes to use the new kernel facilities, rather than requiring the userland scheduling atop the kernel changes that M:N threading would require, and N:1 threading would require just a userland threading library and maybe some limited kernel mechanisms, such as a "wait for multiple events" call, if not already present. Guy Harris (talk) 15:54, 12 June 2020 (UTC)
The section titled "Processes, Threads, and Fibers" and its subsections were started by Daniel Barbalace.
Website: http://www.clearthought.info
From the article:
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)
The potentially leads to misinterpretations.
As it is, unwary readers may think processes are always made up of threads, which is not true. Actually, in many contexts, threads break processes into tasks.
I propose the image, as it is now, to be removed. M. B., Jr. (talk) 23:58, 18 December 2022 (UTC)
So where is the OS concept of a "task", as distinct from a "thread" or a "process", defined?
And what is a "process to task conversion", and how does it "constitute a thread hijack technique (and maybe a thread rescue technique as well?)"
Processes "live in the main memory" in a number of senses: 1) in many operating systems, one resource that a process has and that is shared by all the threads in the process is its address space - not all of which necessiarly resides in main memory - and 2) the OS maintains state about the process, typically in wired main memory. Point 2), however, applies to threads and, in the case of OSes that use the term "task", tasks.
And most CPUs deal with instructions, not threads (in the thread (computing) sense) or tasks. The notion that a CPU is working on a particular "thread", "process", or "task" is, on most CPUs and operating systems, defined by the operating system, not by the CPU. Guy Harris (talk) 20:50, 20 December 2022 (UTC)
pthread_create()
only uses the word "task" in the Rationale, where it refers to the Ada notion of a "task". That's discussed in Ada (programming language) § Concurrency, where it says that "Depending on the implementation, Ada tasks are either mapped to operating system threads or processes, or are scheduled internally by the Ada runtime." The Rationale talks about how to implement Ada tasks atop threads.pthread_cond_broadcast()
uses the word "task" only in the common English sense ("The pthread_cond_broadcast() function is used whenever the shared-variable state has been changed in a way that more than one thread can proceed with its task.").In computing, a task is a unit of execution or a unit of work. The term is ambiguous; precise alternative terms include process, light-weight process, thread (for execution), step, request, or query (for work).
clone()
is used, a task doesn't necessarily correspond to a process; the paper goes on to note that multiple tasks are used to implement multiple threads within a Linux process.As for the quote from Tanenbaum, at least one instance of it is on page 507 of the first edition of Modern Operating Systems, in the beginning of chapter 12 "Processes and Processors in Distributed Systems":
In many distributed systems, it is possible to have multiple threads of control within a process. This ability provides some important advantages, but also introduces various problems. We will study those issues first. Then we come to the subject of how the processors and processes are organized, and see that several different models are possible. Finally we look at processor allocation and scheduling in distributed systems.
Presumably the "several different models" are discussed in section 12.2 "System Models". Two models he describes are the "workstation model" and the "processor pool model".
The examples he gives of the first model involve several workstations on a network. possibly with one or more file server on the same network, with each user doing their own work on their workstation and, if there are file servers, using them for files shared between users. In addition, he describes various schemes for sending jobs to idle workstations, to use those workstations' resources when they're not being used by the user of the workstation.
The second model involves a collection of processors in a machine room, with users having X terminals on their desks, with work assigned to the processors as appropriate. (Think of it as timesharing with a GUI and with the timesharing machine being a cluster.)
Neither of these models have to do with how threads exist within a process.
So if you're using Tanenbaum's quote to say something about the organization of processes and threads, you must be referring to another place where he speaks of "several different models"; if so, could you give the page number, so I can find it in archive.org version of the book? There's a little bit about theading models in section 12.1.4 "Implementing a Threads Package". Guy Harris (talk) 08:39, 21 December 2022 (UTC)
The redirect Thread(OS) has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 November 28 § Thread(OS) until a consensus is reached. Steel1943 (talk) 06:33, 28 November 2023 (UTC)
The redirect Thread(computing) has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 December 18 § Thread(computing) until a consensus is reached. Steel1943 (talk) 16:46, 18 December 2023 (UTC)
The redirect Thread(computer science) has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 December 18 § Thread(computer science) until a consensus is reached. Steel1943 (talk) 16:48, 18 December 2023 (UTC)
The redirect Execution abstraction has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 December 18 § Execution abstraction until a consensus is reached. Steel1943 (talk) 16:59, 18 December 2023 (UTC)
The redirect Current running thread has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 December 18 § Current running thread until a consensus is reached. Steel1943 (talk) 17:02, 18 December 2023 (UTC)