A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-July/007478.html below:

[Python-Dev] PEP 203 Augmented Assignment

[Python-Dev] PEP 203 Augmented Assignment [Python-Dev] PEP 203 Augmented AssignmentM.-A. Lemburg mal@lemburg.com
Thu, 27 Jul 2000 10:02:49 +0200
Guido van Rossum wrote:
> 
> I should add something about the assumed pseudo thread-safety of a+=b.
> 
> I think this assumption is bogus, since we have to load a, do some
> stuff, and then store a, and we can't guarantee that the stuff we do
> is atomic -- in face we *know* it's not if it involves a user-defined
> method.
> 
> Simply put:
> 
>     a += 1 IS NOT ATOMIC!
> 
> Note that C doesn't guarantee that a++ is atomic either, even if a is
> declared volatile.  (I believe there's an atomic data type, but I
> don't think it guarantees atomic ++.  That would be very expensive
> because the VM cache would have to be flushed on multiprocessor
> machines.  The only docs I found are at
> http://www.gnu.org/manual/glibc-2.0.6/html_node/libc_365.html.)

If that's the case, then why do we need augemented assignments
at all ?

(I understood the atomicness being the main argument for
introducing augmented assigns.)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4