Replies: 10 comments 1 reply
-
|
Excellent - you already know that this feature request belongs at this level! However, I wonder if 'brute force' implementation is the correct answer here... If in a controller group, would all waits move to the group level? If so then you can already hack the behaviour by assigning the cv in the compute environments to be the same one (it's an external pointer - reference object). For testing at least. I don't suggest you do this for the release yet, until there's a proper interface at least! |
Beta Was this translation helpful? Give feedback.
-
I wish there were a different way, but I am not sure how. The only alternative I can think of is to wait on each condition variable sequentially, which would not be efficient. If a task resolves in controller B but not controller A, then I might incorrectly spend the full timeout interval waiting for A. |
Beta Was this translation helpful? Give feedback.
-
Yes, it's at the group level. But the implementation will be so easy on my end that I can wait for this #17 before I get started. Once I can use condition variables, both |
Beta Was this translation helpful? Give feedback.
-
|
I'm a bit confused by your last 2 replies. If it works to have the entire group share the same cv, then this can be implemented in mirai as a function that assigns the cv of one compute profile to another or something like that. This would not require a new function at nanonext. |
Beta Was this translation helpful? Give feedback.
-
|
I think I see what you mean: just have all tasks signal to the same cv upon resolution. But I am not sure that would be compatible with shikokuchuo/mirai#78 (reply in thread). |
Beta Was this translation helpful? Give feedback.
-
|
First, condition variables are meant for synchronisation - that is you wait for one to be signalled and then something happens. Now just because there is a counter in there, using it to count is just an incidental by-product - it's not a feature so to speak. So I'm not surprised if using it to synchronise vs. to count will be incompatible - this is not a deficiency. As for waiting for 2 at the same time, that is not implemented by definition of what these are. One solution could be to have 3 condition variables and 2 threads. You wait on one of them (group controller level), and then have 2 threads waiting on each of the others (one for each controller). The side-effect of the cvs being signalled is then for them to signal in turn the one you are waiting on. |
Beta Was this translation helpful? Give feedback.
-
|
As a 'conditionVariable' is an external pointer, we may be able to use an infix operator like: cv %<~% cv2Which would mean the signal from You could forward all the cvs within the controller group to one of them and just wait on the one condition variable. Does this achieve what you want? |
Beta Was this translation helpful? Give feedback.
-
Do you think there is a risk that CVs would drop their nice counting properties at some point?
Yes, that would be perfect! Is it already possible? |
Beta Was this translation helpful? Give feedback.
-
No, it's inherent to what they are.
It's just a thought experiment. It's a pretty naive way to implement this. Possibly I'll be putting in place something else that also achieves what you want. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
This functionality is now merged as of 1512036. |
Beta Was this translation helpful? Give feedback.
-
I really like
nextget("cv")inmirai, and I think it could make polling intargetsmore gentle. However, increw, there is a feature called controller groups which aggregates multiple controllers under a single interface. This feature meets the request from shikokuchuo/mirai#28 for heterogeneous workers. Each controller in the controller group has its own condition variable, and it would be great to be able to wait until at least one of these condition variables gets signaled.Beta Was this translation helpful? Give feedback.
All reactions