I do not think there is any magic number for the number of dependences. On  line 185,
you may observe hc_await_list_constructor allocates enough space (+1) for the number of
events you provide.
Here is a contorted call(?) graph
* , line 51: taskFactory = hc_task_factory_constructor();
* , line 220: taskFactory->create = hc_task_factory_create;
* , line 61 taskFactory->create
* , line 246 (because of bullet_2) hc_task_construct
* , line 272 hc_await_list_constructor
* , line 188 derived->array = checked_malloc(derived->array, sizeof(ocr_event_t*)
On Mar 8, 2013, at 4:09 PM, "Carter, Nicholas P"
In the current OCR code, is there a limit on the number of dependencies an
EDT can have? I’m noticing Heisenbugs when I create tasks with more than 64 dependencies,
and Ganesh mentioned that he thought he remembered Romain saying that the dependency list
was kept as a bit-vector for speed.
Here’s the situation I’m seeing: I’m trying to parallelize the merging of
long subsequences in my merge sort, so, when the merger EDT sees that it’s merging
sequences that are longer than some chunk size, it creates N mergelet tasks that each
perform part of the merge, and a merge_phi task that detects when the mergelets have
finished and signals the task that was waiting on the original merger that it can proceed.
All told, merge_phi has N+3 dependencies, including its data inputs. For N >= 64, the
program occasionally fails, but the failures aren’t reproducible. For N smaller than
that, it seems to work, but I’m still running some tests.
If OCR only tracks 64 dependencies, that’d explain what I’m seeing, since the failures
are very timing-sensitive, and could easily be due to the merge_phi task firing before all
of the tasks it depends on have completed.
OCR-dev mailing list