In a message of Thu, 23 Mar 2006 16:24:39 +0100, Grégoire Dooms writes:
Arthur wrote:
-----Original Message----- From: Laura Creighton [mailto:lac@strakt.com]
And I think he will like tens of thousands of threads, too, though if these just means tens of thousands of chances to modify only part of your complex number, when you wanted an atomic action guaranteed to modify both parts as one, then he may hate it before he likes it. :-)
Sorry - I suspect everyone else is quite done with this, but I'm still bothered by mixed signals.
I would like to be able to present PyGeo as good, sensible code. Not M
useum
Quality, to be sure. But good and responsible.
There is an implication in what you are saying that I am still off the mark. Perhaps I am. But its not fair, in my mind, to throw that at me knowin g that it still has not gotten through to me (and Zelle ?) in what way I am off the mark.
For the life of me I don't see the problem. My class has 2 __slots__ - .real and .imag. It does with them the kind of things that classes do.
How is this class different and less thread safe than an infinite numbe
r of
other classes that do with attributes the kinds of things that classes do with attributes?
This is a complex matter and I'll try to give a very short (hence a little categoric) answer. First of all, IMO Laura was referring to several thousands of lightweight thread such as those found in the Oz/Mozart language (http://www.mozart-oz.org). And that is because we have had a PyPy/Oz sprint two weeks ago where we made plans and prototypes for the integration of some ideas of Mozart into PyPy (mostly logic variables, "search", and constraint programming, micro-threads were already on the g o).
In that language stateful datatypes such as mutable objects are an exception. By default the variable store is a single assignment store. That means when you create a variable (e.g. with this statement X=_ ) it is uninitialized (called unbound). Then when you assign it you cannot rebind it to an other value: X=4 works but if you do X=5 later you get a sort of exception (failure). In a sense = does not do assignment but true mathematical equality (called unification). So you can do 4=X as well as 1+X = 5. The language supports very lightweight threads (having a million of those is no problem), when they try to "use" the value of a variable , they block if the variable is unbound. So you can launch inter-dependant threads accessing values computed by each others without wondering about the synchronization. That is called dataflow concurrency.
In a sense, your mutable complex object is opposite to that approach where (almost) all variables never ever change their value.
I have unintentionally stimulated a CS nerve, apparently. But would s till love to get to the bottom of issue.
HTH :-)
Or get an official CS - proper use case aside - bill of health.
I would refer you to the CTM book: http://www2.info.ucl.ac.be/people/PVR/book.html You will find there lots of interresting ideas about computer language semantics.
Best, -- Grégoire Dooms
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Thank you Grégoire for writing that. Much better than I could. Arthur, classes are not safe either. Say you have class that has two attributes, myclass.price and myclass.tax, and an update method that first assigns a new value to the price, and then, sometime later, even the very next line, assigns tax to be 7% of the price, unless the tax is over 300,000 in which case the tax is 300,000 very simple. And if you only have 1 thread, you are guaranteed that nobody is going to get a hold of an instance of myclass where the price has been changed, but that tax hasn't yet. Only one thing gets to run at all, so there is nobody else, to get a hold of things. Now add threading. Ooops, one thread could be using an instance while the other was updating it. Very bad for you. You need a way to lock' the object and say 'nobody gets to use this thing until I am done with it'. You can implement your own locking mechanism. Or you could use a language type that comes with the language -- a tuple, for instance -- which guarantees this atomicity you want. Then it is the language implementor's headache to make the locking mechanism work. Laura