On 9/14/19 6:35 AM, Steven D'Aprano wrote:
Am I the only one seeing two copies of each of Andrew Barnert's replies?
No.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Am I the only one seeing two copies of each of Andrew Barnert's replies?
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
> On Sep 13, 2019, at 12:21, Richard Musil wrote:
>
>> On Fri, Sep 13, 2019 at 7:28 PM Andrew Barnert via Python-ideas
>> wrote:
>
>> First, I’m pretty sure that, contrary to your claims, C++ does not support
>> this. C++ doesn’t even support shared memory out of the box. The third-party
>>
On Fri, Sep 13, 2019 at 7:28 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> First, I’m pretty sure that, contrary to your claims, C++ does not support
> this. C++ doesn’t even support shared memory out of the box. The
> third-party Boost library does provide it—as long as
On Sep 13, 2019, at 10:11, Richard Musil wrote:
>
> For the atomic operations the lock is on the hardware level (i.e. implemented
> in the CPU, across the mem BUS, cache, etc.), from the user perspective, it
> looks only like executing a particular (atomic) op-code.
>
On Fri, 13 Sep 2019 10:27:10 -0700
Andrew Barnert via Python-ideas
wrote:
>
> (If you want a shiny modern solution instead, this looks like one of the few
> cases where hardware TM support can probably speed things up relatively
> easily, which would be a fun project to work on…)
Hardware
On Sep 13, 2019, at 09:31, Vinay Sharma via Python-ideas
wrote:
>
> multiprocessing.Value can be synchronised using a lock, but if I have
> multiple multiprocessing.Value(s) which I want to synchronise between two
> processes, then I will have to pass a lock for each multiprocessing.Value.
First, I’m pretty sure that, contrary to your claims, C++ does not support
this. C++ doesn’t even support shared memory out of the box. The third-party
Boost library does provide it—as long as you only care about systems that
correctly supports POSIX shared memory, and Windows, and as long as
On Fri, Sep 13, 2019 at 6:56 PM Rhodri James wrote:
> I repeat, how does this work? If you want atomicity across processes,
> you need some kind of lock at some level.
>
For the atomic operations the lock is on the hardware level (i.e.
implemented in the CPU, across the mem BUS, cache, etc.),
On 13/09/2019 17:31, Vinay Sharma wrote:
multiprocessing.Value can be synchronised using a lock, but if I have multiple
multiprocessing.Value(s) which I want to synchronise between two processes,
then I will have to pass a lock for each multiprocessing.Value. Therefore
having a
On Fri, Sep 13, 2019 at 6:27 PM Rhodri James wrote:
> On 13/09/2019 17:07, Vinay Sharma wrote:
> > Please see my second mail in this thread, where I have comprehensively
> explained what I mean by atomic types.
> > It is nothing but multiprocessing.Value, which can have an Atomic
> variant to be
If you see my first mail, I have mentioned that gcc has support for atomic
builtins, which can be used to support atomic behaviour.
You can refer gcc’s documentation for the same at
https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/_005f_005fsync-Builtins.html#g_t_005f_005fsync-Builtins
On 13/09/2019 17:07, Vinay Sharma wrote:
Please see my second mail in this thread, where I have comprehensively
explained what I mean by atomic types.
It is nothing but multiprocessing.Value, which can have an Atomic variant to be
used across processes.
Doesn't multiprocessing.Value already
Please see my second mail in this thread, where I have comprehensively
explained what I mean by atomic types.
It is nothing but multiprocessing.Value, which can have an Atomic variant to be
used across processes.
>>> On 13-Sep-2019, at 8:37 PM, Rhodri James wrote:
>> On 13/09/2019 14:32,
On 13/09/2019 14:32, Vinay Sharma via Python-ideas wrote:
As you said there can be lot of possible use cases for the proposed
feature, since there are lot’s of use cases for a lock. I can tell
you some cases which I am facing.
I don't in principle object to having language support for tricky
Hi Vinay,
I see. I agree agregating statistics is a reasonable use case.
Still, maintaining atomic types in the standard library sounds
non-trivial for a rather niche feature. Perhaps you want to implement
them as a third-party project and publish it on PyPI?
multiprocessing already provides
Hi Antoine,
As you said there can be lot of possible use cases for the proposed feature,
since there are lot’s of use cases for a lock. I can tell you some cases which
I am facing.
Let’s say I have a parent process which spawns lots of worker processes to
serve some requests. Now the parent
On Tue, 10 Sep 2019 18:59:55 +1000
Chris Angelico wrote:
> On Tue, Sep 10, 2019 at 6:55 PM Antoine Pitrou wrote:
> >
> > On Mon, 9 Sep 2019 19:04:35 +1000
> > Chris Angelico wrote:
> > > On Mon, Sep 9, 2019 at 12:34 AM Vinay Sharma via Python-ideas
> > > wrote:
> > > >
> > > > Currently,
On Tue, Sep 10, 2019 at 6:55 PM Antoine Pitrou wrote:
>
> On Mon, 9 Sep 2019 19:04:35 +1000
> Chris Angelico wrote:
> > On Mon, Sep 9, 2019 at 12:34 AM Vinay Sharma via Python-ideas
> > wrote:
> > >
> > > Currently, C++ has support for atomic types, on which operations like
> > > add, sub,
Hi Vinay,
On Mon, 09 Sep 2019 08:23:48 -
Vinay Sharma via Python-ideas
wrote:
>
> Also, as far as I know (might be wrong) Value is stored in shared memory and
> is therefore very fast also. So, what I am proposing is a similar object to
> value to which operations like add, sub, xor,
On Mon, 9 Sep 2019 19:04:35 +1000
Chris Angelico wrote:
> On Mon, Sep 9, 2019 at 12:34 AM Vinay Sharma via Python-ideas
> wrote:
> >
> > Currently, C++ has support for atomic types, on which operations like add,
> > sub, xor, etc can be done atomically, thereby avoiding data races.
> > Having
On Mon, Sep 9, 2019, 09:27 Vinay Sharma via Python-ideas <
python-ideas@python.org> wrote:
> Also, I didn't mean simple variables to be atomic. I just mean that
> some objects which are frequently being used across processes in
> multiprocessing can have some atomic operations/methods.
>
So, as
On Sep 9, 2019, at 01:23, Vinay Sharma wrote:
> Also, I didn't mean simple variables to be atomic. I just mean that some
> objects which are frequently being used across processes in multiprocessing
> can have some atomic operations/methods.
It sounds like all you want is an
Oh, thanks! it is much more palpable now!
On Mon, Sep 9, 2019, 05:23 Vinay Sharma wrote:
> Hi,
> I apologise for my poor explanation of what I mean. I should have been
> more comprehensive in describing the idea.
>
> First of all I am only concerned with synchronization across multiple
>
On Mon, Sep 9, 2019 at 12:34 AM Vinay Sharma via Python-ideas
wrote:
>
> Currently, C++ has support for atomic types, on which operations like add,
> sub, xor, etc can be done atomically, thereby avoiding data races.
> Having such a support will be very helpful in Python.
On Mon, Sep 9, 2019 at
Hi,
I apologise for my poor explanation of what I mean. I should have been more
comprehensive in describing the idea.
First of all I am only concerned with synchronization across multiple processes
only, and not threads. Therefore I never mentioned multi-threading in my
original post.
I am
May I ask how acquainted you ar with parallel code, including
multi-threading, in Python?
Because as far as I can perceive none of the types or operations you
mention have
any race conditions in multi-threaded Python code, and for multi-process or
async code that
is not a problem by design but
27 matches
Mail list logo
