[Python-Dev] Proposed PEP on concurrent programming support

[Matt Joiner]

On Thu, Jan 12, 2012 at 11:01 AM, Mike Meyer <mwm at mired.org> wrote:
> On Wed, 4 Jan 2012 00:07:27 -0500
> PJ Eby <pje at telecommunity.com> wrote:
>
>> On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <mwm at mired.org> wrote:
>> > A suite is marked
>> > as a `transaction`, and then when an unlocked object is modified,
>> > instead of indicating an error, a locked copy of it is created to be
>> > used through the rest of the transaction. If any of the originals
>> > are modified during the execution of the suite, the suite is rerun
>> > from the beginning. If it completes, the locked copies are copied
>> > back to the originals in an atomic manner.
>> I'm not sure if "locked" is really the right word here.  A private
>> copy isn't "locked" because it's not shared.
>
> Do you have a suggestion for a better word? Maybe the "safe" state
> used elsewhere?
>
>> > For
>> > instance, combining STM with explicit locking would allow explicit
>> > locking when IO was required,
>> I don't think this idea makes any sense, since STM's don't really
>> "lock", and to control I/O in an STM system you just STM-ize the
>> queues. (Generally speaking.)
>
> I thought about that. I couldn't convince myself that STM by itself
> sufficient. If you need to make irreversible changes to the state of
> an object, you can't use STM, so what do you use? Can every such
> situation be handled by creating "safe" values then using an STM to
> update them?
>
>       <mike
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com

IMHO STM by itself isn't sufficient. Either immutability, or careful
use of references protected by STM amounting to the same are the only
reasonable ways to do it. Both also perform much better than the
alternatives.