Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #45539
| References | <7baacf5a-0c50-4935-ad5b-148c208d759b@googlegroups.com> <13lfp8lds6e2e41rtsnvqimcb6inu7p28o@invalid.netcom.com> <BLU176-W444B989132C26C3A305CB7D7AE0@phx.gbl> |
|---|---|
| Date | 2013-05-19 10:38 +1000 |
| Subject | Re: Please help with Threading |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.1825.1368923899.3114.python-list@python.org> (permalink) |
On Sun, May 19, 2013 at 10:02 AM, Carlos Nepomuceno <carlosnepomuceno@outlook.com> wrote: > I didn't know Python threads aren't preemptive. Seems to be something really old considering the state of the art on parallel execution on multi-cores. > > What's the catch on making Python threads preemptive? Are there any ongoing projects to make that? Preemption isn't really the issue here. On the C level, preemptive vs cooperative usually means the difference between a stalled thread locking everyone else out and not doing so. Preemption is done at a lower level than user code (eg the operating system or the CPU), meaning that user code can't retain control of the CPU. With interpreted code eg in CPython, it's easy to implement preemption in the interpreter. I don't know how it's actually done, but one easy implementation would be "every N bytecode instructions, context switch". It's still done at a lower level than user code (N bytecode instructions might all actually be a single tight loop that the programmer didn't realize was infinite), but it's not at the OS level. But none of that has anything to do with multiple core usage. The problem there is that shared data structures need to be accessed simultaneously, and in CPython, there's a Global Interpreter Lock to simplify that; but the consequence of the GIL is that no two threads can simultaneously execute user-level code. There have been GIL-removal proposals at various times, but the fact remains that a global lock makes a huge amount of sense and gives pretty good performance across the board. There's always multiprocessing when you need multiple CPU-bound threads; it's an explicit way to separate the shared data (what gets transferred) from local (what doesn't). ChrisA
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Please help with Threading Jurgens de Bruin <debruinjj@gmail.com> - 2013-05-18 01:58 -0700
Re: Please help with Threading Peter Otten <__peter__@web.de> - 2013-05-18 11:09 +0200
Re: Please help with Threading Jurgens de Bruin <debruinjj@gmail.com> - 2013-05-18 04:23 -0700
Re: Please help with Threading Peter Otten <__peter__@web.de> - 2013-05-18 14:01 +0200
Re: Please help with Threading Dave Angel <davea@davea.name> - 2013-05-18 09:55 -0400
Re: Please help with Threading Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-18 15:28 -0400
RE: Please help with Threading Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-19 03:02 +0300
Re: Please help with Threading Chris Angelico <rosuav@gmail.com> - 2013-05-19 10:38 +1000
Re: Please help with Threading Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-19 17:46 -0400
Re: Please help with Threading Chris Angelico <rosuav@gmail.com> - 2013-05-20 07:52 +1000
Re: Please help with Threading Dave Angel <davea@davea.name> - 2013-05-19 21:04 -0400
Re: Please help with Threading Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-19 22:58 -0400
Re: Please help with Threading Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-19 23:25 -0400
Re: Please help with Threading Fábio Santos <fabiosantosart@gmail.com> - 2013-05-20 07:25 +0100
Re: Please help with Threading Jurgens de Bruin <debruinjj@gmail.com> - 2013-06-02 18:47 -0700
csiph-web