> you'd likely need to increment workID count when submitting a task and not
> after checking tryRecv
For anyone else reading this, we're talking past each other here I suspect,
because the code does do the right thing once an `initLock` is added. What
happens for submission is it only submits
> So, after much debugging... Always use initLock on your locks. Don't ever
> forget it otherwise the lock will "work" without actually doing what it's
> supposed to. You might also need deinitLock then.
Oops, sorry I forgot that I'd changed that too. Yes, definitely init them (and
conds as wel
SOLVED
So, after much debugging... Always use `initLock` on your locks. Don't ever
forget it otherwise the lock will "work" without actually doing what it's
supposed to. You might also need `deinitLock` then.
> The logic in your loop will try and submit...
Ah good catch with the `while workID < NSUBMISSIONS` submission loop, Thank
you! I tried too hard to make a tidy minimal example and introduced this bug
thinking I could get rid of my break condition for cleanliness. Edited the code
and output abo
There are a couple of logic flaws in your job pool example which are causing
your issues. Nothing particularly Nim specific, but here's a breakdown.
while workID < NSUBMISSIONS: # This will run ceil(NSUBMISSIONS / NTHREADS)
* NTHREADS items
for thread in pool.mitems:
I've spent a few days on this and boiled this down to a minimal example. Can an
expert with Nim parallelism please tell me where I'm going wrong here?
Output changes from run to run (is stochastic) but I did not intend that and do
not see how this can be. Here are several runs in a row of a very
