-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadlock/livelock/etc. prevention #36
Comments
|
Yes, that's exactly how I understood it. Sorry I wasn't specific enough in my description. What I meant is that there is a fixed number of threads (workers) and they get some work "over the time" (but maybe this is another misunderstanding on my side of the source code and all the work is scheduled up-front in a fixed manner without any dependency on "time" unlike e.g. in work stealing scenarios) whether each thread gets to |
The scheduler is very primitive see here. Each thread is only assigned a redex, and then it just waits. A task scheduler is one of the improvements we'd like to make if we manage to scale this project. |
Then I'd recommend a work-stealing scheduler. Ideally one optimized for micro tasks (the state of the art is still Weave - you can easily skip the binary generation and use only the generated C code as Nim is just a clever transpiler). |
Yep, something like that is very high on my dream wishlist! |
I saw the implementation of
u64 normal_join(u64 tid) {...}
inruntime.c
and its use and wonder whether the HVM language (or is it HOVM language?) guarantees no deadlocks/livelocks in this case?If so, how? If not, then this should be taken into consideration if I understood the inner workings correctly.
I'm unable to do any mathematical proofs of this, so I've turned to asking about this 😉.
The text was updated successfully, but these errors were encountered: