Possible suggestion for removing the GIL

[Chris Mellon]

On 9/13/07, Prateek <surekap at gmail.com> wrote:
> On Sep 13, 1:36 pm, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
> > Prateek wrote:
> > > Hi,
> >
> > > Recently there was some talk on removing the GIL and even the BDFL has
> > > written a blog post on it.
> > > I was trying to come up with a scalable and backwards compatible
> > > approach for how to do it.
> >
> > > I've put my thoughts up in a blog post - and I'd really like to hear
> > > what the community thinks of it.
> > > Mainly it revolves around dedicating one core for executing
> > > synchronized code and doing context switches instead of acquiring/
> > > releasing locks.
> >
> > Where is the gain? Having just one core doesn't give you true parallelism -
> > which is the main reason behind the cries for a GIL-less Python.
> >
> > Diez
>
> Diez,
>
> I was talking of dedicating one core for synchronized code. In the
> case of a threaded app on two cores, one core would be dedicated to
> synchronized code and the other would run non-sync code (effectively
> behaving like a single threaded machine). However, on machines with n
> cores where n > 2 cores, we would have n-1 cores available to run code
> in parallel.
>

What you're describing would have the same characteristics as the
current code - code that is able to execute without the GIL held
already will run in parallel on a multi-core machine.