Difference between revisions of "Talk:COMP 3000 Essay 1 2010 Question 7"
(→Log) |
|||
| Line 35: | Line 35: | ||
== Log == | == Log == | ||
Please maintain a log of your activities in the Log Section. So that we can keep track of the evolution of the essay. -Gautam | Please maintain a log of your activities in the Log Section. So that we can keep track of the evolution of the essay. --[[User:Gautam|Gautam]] | ||
Moved around some info for clarity, everyone should post your interpretation of the question in simplest possible English so we`re on the same page (as someone, maybe me, seems to have the wrong idea about what we`re trying to talk about) | Moved around some info for clarity, everyone should post your interpretation of the question in simplest possible English so we`re on the same page (as someone, maybe me, seems to have the wrong idea about what we`re trying to talk about) | ||
Revision as of 00:59, 10 October 2010
The Question
Post your interpretation of the question.
Original:
How is it possible for systems to supports millions of threads or more within a single process? What are the key design choices that make such systems work - and how do those choices affect the utility of such massively scalable thread implementations?
Rannath:
How do we support absurd numbers of threads (in the millions)? Discuss key design choices.
Basically the question is about number and scalability of threads not the gross mechanics. I think we can safety limit ourselves to software-side only.
Group 7
Let us start out by listing down our names and email id (preffered).
Gautam Akiwate <gautam.akiwate@gmail.com>
Patrick Young(rannath) <rannath@gmail.com>
vG Vivek - support.tamiltreasure@gmail.com
Henry Irving <sens.henry@gmail.com>
Guidelines
Raw info should have some indication of where you got it for citation.
Claim your info so we don't need to dig for who got what when we need clarification.
Feel free to provide info for or edit someone else's info, just keep their signature so we can discuss changes
sign changes (once) preferably without time stamps Ex: --Rannath
Please maintain a log of your activities in the Log Section. So that we can keep track of the evolution of the essay. --Gautam
Log
Please maintain a log of your activities in the Log Section. So that we can keep track of the evolution of the essay. --Gautam
Moved around some info for clarity, everyone should post your interpretation of the question in simplest possible English so we`re on the same page (as someone, maybe me, seems to have the wrong idea about what we`re trying to talk about)
<Add your future activities here>
Essay Rough
Start by placing the info here so we can sort through it. I'm going to go into full research/essay writing mode on Sunday if there isn't enough here.
So far we have: Three design choices I've seen:
- Smallest possible footprint per-thread (being extremely light weight) - from everywhere --Rannath 00:28, 7 October 2010 (UTC)
- least number (none if at all possible) of context switches per-thread - some linux implementation --Rannath 00:28, 7 October 2010 (UTC)
- use of a "thread pool" - java picothreads article --Rannath 00:28, 7 October 2010 (UTC)
The idea is to reduce processor time and storage needed per-thread so you can have more in the same amount of space.--Rannath 00:28, 7 October 2010 (UTC)
Splitting this off because it's not technically part of the answer
Multithreading generally occurs by time-division multiplexing. It makes it possible for the processor to switch between different threads but it happens so fast that the user sees it as it is running at the same time. User:vG
Things that we need to cover in the essay:--Gautam 19:35, 7 October 2010 (UTC)
(A)Design Decisions
1. Type of threading (1:1 1:N M:N) 2. Signal handling - we might be able to leave this out as it seems some "light weight" threads use no signals 3. Synchronisation 4. Memory Handling
Things we might want also to cover in the essay (move non-essentials here): --Rannath 04:43, 10 October 2010 (UTC)
(A)Design Decisions
1. Brief History of threading 2. examples of attempts at getting absurd numbers of threads (failures and successes) 3. other types of threading, including heavy weight and processes
(B)Kernel
1. Program Thread manipulation through system calls --Hirving 20:05, 7 October 2010 (UTC)
(C)Hardware --Hirving 19:55, 7 October 2010 (UTC)
1. Simultaneous Multithreading 2. Multi-core processors
Sources
Short history of threads in Linux and new implementation of them. NPTL: The New Implementation of Threads for Linux Gautam 22:18, 5 October 2010 (UTC)
This paper discusses the design choices Native POSIX Threads Gautam 22:11, 5 October 2010 (UTC)
A paper with low-footprint(lightweight) threads vs kernel threads (for Java :( ) http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.32.9043&rep=rep1&type=pdf --Rannath 00:23, 6 October 2010 (UTC)
A comparison of lightweight threads http://eigenclass.org/hiki/lightweight-threads-with-lwt --Rannath 00:23, 6 October 2010 (UTC)
A lightwight thread implementation for Unix http://www.usenix.org/publications/library/proceedings/sa92/stein.pdf --Rannath 00:49, 6 October 2010 (UTC)
Gbint 19:50, 5 October 2010 (UTC) Not in this group, but I thought that this paper was excellent: http://www.sandia.gov/~rcmurph/doc/qt_paper.pdf
Difference between single and multi threading http://wiki.answers.com/Q/Single_threaded_Process_and_Multi-threaded_Process [[vG]
Implementation of Scalable Blocking Locks using an Adaptative Thread Scheduler --Gautam 19:35, 7 October 2010 (UTC)
Research Group working on Simultaneous Multithreading Simultaneous Multithreading --Hirving 19:58, 7 October 2010 (UTC)