Possible suggestion for removing the GIL

[Prateek]

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.

http://www.brainwavelive.com/blog/in...eter-Lock.html

Thanks,
Prateek Sureka

[Diez B. Roggisch]

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

[Prateek]

On Sep 13, 1:36 pm, "Diez B. Roggisch" <[e-mail]:

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.

Prateek

[Chris Mellon]

On 9/13/07, Prateek <su*****@gmail.comwrote:

On Sep 13, 1:36 pm, "Diez B. Roggisch" <[e-mail]:

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.

[Bryan Olson]

Prateek wrote:
[...]

Mainly it revolves around dedicating one core for executing
synchronized code and doing context switches instead of acquiring/
releasing locks.

http://www.brainwavelive.com/blog/in...eter-Lock.html

Context switches are generally more expensive than acquiring
and release locks. Most systems' run-queues are protected by
locks. The context switches at issue all involve the
dedicated core, so I do not see any parallelism advantage.
--
--Bryan