[Edu-sig] Properties use case

[Laura Creighton]

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 at 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 at 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