Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Re: Coroutines in Perl

by mrd (Beadle)
on May 07, 2004 at 17:46 UTC ( [id://351552]=note: print w/replies, xml ) Need Help??


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

The main diffrenece between coroutines and threads is that threads are meant to run in "paralel" (and they *really* do on multiprocessor machines), while coroutines are not. Therefore, when using coroutines, there is no need to worry about synchronisation, race conditions, starvation, you know ... stuff that plagues "multithreaded programming".

For an excelent discussion of coroutines and how they work in Lua, see this paper:

http://www.inf.puc-rio.br/~roberto/docs/corosblp.pdf

Replies are listed 'Best First'.
Re: Re: Re: Coroutines in Perl
by bsb (Priest) on May 08, 2004 at 04:47 UTC
    Threads are also pre-emptive, even on a single CPU. Coroutines are cooperatively yielding.
Re^3: Coroutines in Perl
by PhilHibbs (Hermit) on May 10, 2004 at 16:01 UTC
    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.
      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://351552]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (5)
As of 2024-03-28 12:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found