Easy way to get access to cmpxchg?
It'd be nice to be able to do something like this in rpython: compare_and_swap(foo.bar, oldval, newval) Or basically the cmpxchg. How hard would it be to get this in? Timothy -- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth)
Well, I know that Python uses references, so that wouldn't be possible in normal Python code without using stack inspection. In RPython, which restricts all of that, it'd have to be another translator feature that uses magic to get things done. On Fri, Feb 21, 2014 at 6:39 PM, Timothy Baldridge <tbaldridge@gmail.com>wrote:
It'd be nice to be able to do something like this in rpython:
compare_and_swap(foo.bar, oldval, newval)
Or basically the cmpxchg. How hard would it be to get this in?
Timothy
-- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth)
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
Hi Timothy, On 22 February 2014 01:39, Timothy Baldridge <tbaldridge@gmail.com> wrote:
compare_and_swap(foo.bar, oldval, newval)
At some point we added a way to do it (basically you can do it yourself, by writing a one-line function in C and calling it). We no longer do that: it's too much of a mess if you start having non-GIL-protected code written in RPython. Either you are extremely, extremely careful, or random things will explode. What we do instead, e.g. in the stm branches, is to write more C code. For the complete parts that really need to run without any GIL protection, C is better than RPython after all. A bientôt, Armin.
What's the best way to tell rpython not to release the GIL during a given block of code? I haven't been able to find any code that describes when the GIL is acquired or when control could switch over to another thread. I'd prefer to have my interpreter bytecodes be atomic from the point of view from the program. If I had that, then I could easily build a psudo compare_and_swap by doing this: dont_release_gil() if foo.bar == oldval: foo.bar = newval enable_gil_releasing() Thanks, Timothy On Sat, Feb 22, 2014 at 12:13 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Timothy,
On 22 February 2014 01:39, Timothy Baldridge <tbaldridge@gmail.com> wrote:
compare_and_swap(foo.bar, oldval, newval)
At some point we added a way to do it (basically you can do it yourself, by writing a one-line function in C and calling it). We no longer do that: it's too much of a mess if you start having non-GIL-protected code written in RPython. Either you are extremely, extremely careful, or random things will explode. What we do instead, e.g. in the stm branches, is to write more C code. For the complete parts that really need to run without any GIL protection, C is better than RPython after all.
A bientôt,
Armin.
-- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth)
Actually I just found this article: http://stackoverflow.com/questions/12166268/wheres-the-gil-in-pypy and it seems that the GIL is a feature specific to each interpreter. The link on that code lead me to module/thread/gil.py and that looks like it contains most of what I need. Thanks! Timothy On Mon, Feb 24, 2014 at 1:41 PM, Timothy Baldridge <tbaldridge@gmail.com>wrote:
What's the best way to tell rpython not to release the GIL during a given block of code? I haven't been able to find any code that describes when the GIL is acquired or when control could switch over to another thread. I'd prefer to have my interpreter bytecodes be atomic from the point of view from the program. If I had that, then I could easily build a psudo compare_and_swap by doing this:
dont_release_gil() if foo.bar == oldval: foo.bar = newval enable_gil_releasing()
Thanks,
Timothy
On Sat, Feb 22, 2014 at 12:13 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Timothy,
On 22 February 2014 01:39, Timothy Baldridge <tbaldridge@gmail.com> wrote:
compare_and_swap(foo.bar, oldval, newval)
At some point we added a way to do it (basically you can do it yourself, by writing a one-line function in C and calling it). We no longer do that: it's too much of a mess if you start having non-GIL-protected code written in RPython. Either you are extremely, extremely careful, or random things will explode. What we do instead, e.g. in the stm branches, is to write more C code. For the complete parts that really need to run without any GIL protection, C is better than RPython after all.
A bientôt,
Armin.
-- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth)
-- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth)
yes, GIL is specific, but the PyPy GC is not really ready to do multithreading. You would need a different (more thread aware) GC in order to do that. Right now it assumes someone is holding some sort of lock when allocating. On Mon, Feb 24, 2014 at 9:47 PM, Timothy Baldridge <tbaldridge@gmail.com> wrote:
Actually I just found this article: http://stackoverflow.com/questions/12166268/wheres-the-gil-in-pypy and it seems that the GIL is a feature specific to each interpreter. The link on that code lead me to module/thread/gil.py and that looks like it contains most of what I need.
Thanks!
Timothy
On Mon, Feb 24, 2014 at 1:41 PM, Timothy Baldridge <tbaldridge@gmail.com> wrote:
What's the best way to tell rpython not to release the GIL during a given block of code? I haven't been able to find any code that describes when the GIL is acquired or when control could switch over to another thread. I'd prefer to have my interpreter bytecodes be atomic from the point of view from the program. If I had that, then I could easily build a psudo compare_and_swap by doing this:
dont_release_gil() if foo.bar == oldval: foo.bar = newval enable_gil_releasing()
Thanks,
Timothy
On Sat, Feb 22, 2014 at 12:13 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Timothy,
On 22 February 2014 01:39, Timothy Baldridge <tbaldridge@gmail.com> wrote:
compare_and_swap(foo.bar, oldval, newval)
At some point we added a way to do it (basically you can do it yourself, by writing a one-line function in C and calling it). We no longer do that: it's too much of a mess if you start having non-GIL-protected code written in RPython. Either you are extremely, extremely careful, or random things will explode. What we do instead, e.g. in the stm branches, is to write more C code. For the complete parts that really need to run without any GIL protection, C is better than RPython after all.
A bientôt,
Armin.
-- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth)
-- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth)
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
participants (4)
-
Armin Rigo -
Maciej Fijalkowski -
Ryan Gonzalez -
Timothy Baldridge