On 05/06/2014 07:15 PM, Kimpe, Dries Leon Tom wrote:
* Curry, Matthew Leon <[email protected]> [2014-05-06 22:56:03]:
[...]
2. We discussed spawning extra threads in the server so that we can have real parallelism while also using Aesop�s concurrency model. I seem to remember that this is possible, but we never discussed in detail. How would we accomplish this? You can use the aethread resource, which causes the statements following the call to the resource to be executed on a dedicated thread. That thread will be able to call blocking calls without blocking aesop threads. aethreads work until a blocking call into a resource is executed, at which point control goes back into the aesop scheduler, correct? What if we want to have, say, one aesop-aware thread per core alive through the whole server execution? That's very difficult to do, since aesop tends to take threads and keep them for a while. In other words, if any of your other threads call a blocking function that thread might not be released any time soon, and some other thread might continue executing code following the blocking call.
There might be something that can be done about this, but it could be complicated.
Depending on the specifics of the use case (what exactly you want the threads to do) it might be easier to just spawn threads like you normally would. When it comes down to it you can do this in .ae code like you would in .c code for the most part. In triton, for example, we keep a some dedicated threads around throughout execution to drive progress on Mercury at all times. In that case that was the easiest route to get the behavior that we wanted. I might be getting off in the weeds at this point, but we can share that chunk of code (the part that drives Mercury) if you guys are interested. It has several triton-isms in it (types, error conventions, etc.) but it might be a helpful example or we consider cleaning it up into a more general-purpose shared component. -Phil
However, if you simply want more aesop concurrency, then you would use a lonely pbranch. I.e. a pbranch without an enclosing pwait. I assume that a lonely pbranch is still scheduled serially onto one core with all the other pbranches. Correct, though in most cases it won't be serially. Any available thread in aesop (from resources, or aethread calls) can be used to execute any runnable code. So in most instances, there are usually a number of threads busy executing pbranches.
Dries