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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
