On 14 Jul 2005 05:10:38 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid> 
wrote:
>Andreas Kostyrka <[EMAIL PROTECTED]> writes:
>> Basically the current state of art in "threading" programming doesn't
>> include a safe model. General threading programming is unsafe at the
>> moment, and there's nothing to do about that. It requires the developer
>> to carefully add any needed locking by hand.
>
>So how does Java do it?  Declaring some objects and functions to be
>synchronized seems to be enough, I thought.

Multithreaded Java programs have thread-related bugs in them too.  So it 
doesn't seem to be enough.  Like Python's model, Java's is mostly about 
ensuring internal interpreter state doesn't get horribly corrupted.  It doesn't 
do anything for application-level state.  For example, the following (Python, 
because it's way too early to write Java, but a straight port to Java would be 
broken in exactly the same way) program is not threadsafe:

things = []

def twiddle(thing):
    if thing in things:
        print 'got one'
        things.remove(thing)
    else:
        print 'missing one'
        things.append(thing)

The global list will never become corrupted.  stdout will always be fine 
(although perhaps a little weird).  The objects being appended to and removed 
from the list are perfectly safe.

But the program will double append items to the list sometimes, and raise 
ValueErrors from the list.remove() call sometimes.

Java's model isn't really too far from the traditional one.  It's a tiny bit 
safer, perhaps, but that's all.  For something different, take a look at 
Erlang's mechanism (this has been ported to Python, although I have heard 
nothing of the result since its release announcement, I wonder how it's doing?)

Hope this helps,

Jp
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to