Hi Armin:
On Thursday, October 24, 2013 4:38 AM, Armin Rigo <ar...@tunes.org> wrote:
> I can't answer your questions without
>knowing exactly what you're planning. Sorry if I forgot, I know you
>mentioned it several times here. I still have a hard time figuring
>out the real goal, rather than implementation details. For example,
>"I want to implement what is described in paper X about language Y" is
>often unrelated to "can I use pypy-stm's GIL approach".
The University of Chicago/Microsoft Research paper "Scalable Join Patterns"
(http://www.mpi-sws.org/~turon/scalable-joins.pdf) outlines an approach for
implementing join patterns using essentially lock-free bags, optimistic locking
and techniques for guaranteeing liveness. For the sake of this discussion,
ignore the term "join pattern" : substitute it with "channel."
A bit more context - I have looked at the C code for the Go channel
implementation and said "wow, there is a lot of locking there"! I also have
been following conversations concerning race conditions and the race detector
(based on thread sanitizer) and asking myself: pypy-stm could do this.
For some experiments, I want pypy-stm for two reasons:
1) There is no GIL so I can compare the results of say a lock-free queue to
say, Python thread-safe queues (I am not sure of their utility in pypy-stm).
2) I may need some of pypy-stm's functionality.
Is there anything wrong with this reasoning?
>rpython.rlib.atomic_ops.
Yes.
>Note however that the core of pypy-stm is directly implemented in C, not >in
>RPython.
Okay I'll look at the code. A little while back I looked at RSTM.
>I guess not right now, but that should be easy if someone cares.
I care. What do I need to look at?
Cheers,
Andrew
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
