Concurrency Models

Allison Randal allison at parrot.org
Wed Jul 14 02:52:48 UTC 2010


On 7/13/10 5:02 PM, Andrew Whitworth wrote:
> I purposefully left this vague, there are really too many options to
> enumerate. Thread-safe PMCs (thread-safe queue, etc) would be nice.
> Also fitting into this category would be e.g. a Mutex PMC or a family
> of locking PMCs. A "Select" PMC to divvy out IO requests would work
> well with a Semaphore type, for instance. In any case, there would
> likely be several PMC types we would need to add to support the kinds
> of mechanisms people are going to want.

Yah, that's what I figured. Another possibility would have been a 
threading infrastructure library set like Threading Building Blocks, or 
OpenMP, but I didn't think you were headed in that direction.

> Chandon's project is going well, his only blocker is the surprisingly
> broken (and under-tested) state of the scheduler, which he's picking
> apart and putting back together.

It doesn't entirely surprise me, people don't use threading, so it 
doesn't get real usage testing which is the best way to exercise the 
edge cases and figure out what the core tests should be testing. Partly 
it's a bit of a chicken and egg problem, people try using threads, run 
into problems and don't go further. But a bigger factor is that Parrot 
doesn't have any large, real-world applications running on it yet. (NQP 
doesn't count, because it is tools for building languages for building 
real-world applications.) The classes of problems being solved right now 
in Parrot are too small for threads to be of much benefit.

The scheduler as it's currently implemented also has some ugly bits that 
were shoehorned in for backward compatibility with other, older subsystems.

> At the end of his project, I have no
> doubt that we will have a working threading model of some variety.
> What we won't have is any way to safely share PMCs between threads, so
> any tests or demonstrations he does will probably need to explicitly
> avoid those situations. We will have threads, but I think they will be
> considered "unusable" in the practical sense if we can't serialize
> access to shared PMCs.

Another chicken and egg problem here: he can't implement shared 
variables, because he doesn't know which way to implement shared 
variables, because people aren't using shared variables, because he 
doesn't have an implementation of shared variables...

Since it's a prototype, he has the freedom to pick the model that works 
best for the prototype and run with it. Either message passing or a very 
simple custom locking variable type would be my first choices in this 
context. It just needs to demonstrate that sharing works, not address a 
broad range of potential real-world use cases.

Allison


More information about the parrot-dev mailing list