Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^3: Coroutines in Perl

by PhilHibbs (Hermit)
on May 10, 2004 at 16:01 UTC ( [id://352116]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Coroutines in Perl
in thread Coroutines in Perl

threads are meant to run in "paralel"..., while coroutines are not. Therefore, when using coroutines, there is no need to worry about synchronisation, race conditions, starvation, you know ...
They do effectively run in parallel, and you can get synchronisation problems. These are a symptom of any non-linear algorithm, whether it uses threading or not.

Replies are listed 'Best First'.
Re: Re^3: Coroutines in Perl
by mrd (Beadle) on May 11, 2004 at 08:10 UTC
    By "parallel" I meant "concurrently".

    And there can be no two coroutines running at the same time. There is always only one coroutine running, while all others are waiting for it to "yield" or "return".

    What synchronisation problems with coroutines are you referring to?

    Implementing a classic "producer-consumer" system using coroutines is straight-forward and natural. No extra mechanisms are necesary to ensure that the "consumer" is reading "valid data" or that the "producer" isn't overwitting unprecessed (by the consumer) data.

    Now, one can build coroutines on top of threads, as Python does (*), but that is just an implementation detail that a programmer doesn't need to care about.

    (*) I'm referring to the "Coroutine.py" library distributed with Python, which for some reason isn't mentioned as part of the "Python Standard Library".

      With a pair of coroutines working togetger, you are unlikely to get synchronisation problems unless they are badly written. However, in the more general case of continuations, I don't think you can disregard synchronisation problems with coroutines, in the same way that you can't disregard sync problems with emulating threads on a single CPU.

      If all your locking or resource acquisition is done in a single step, then you should be ok, but if there are any yields in between resource acquisitions, then you need to avoid deadlock. I suppose the co-operative nature of continuations means that you can avoid them easily, so you may be right.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://352116]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (2)
As of 2024-04-25 22:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found