diff options
Diffstat (limited to '')
| -rw-r--r-- | src/solvers/h48/gendata_h48.h | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/src/solvers/h48/gendata_h48.h b/src/solvers/h48/gendata_h48.h index a993f53..3445570 100644 --- a/src/solvers/h48/gendata_h48.h +++ b/src/solvers/h48/gendata_h48.h | |||
| @@ -284,6 +284,19 @@ gendata_h48h0k4_return_size: | |||
| 284 | return H48_TABLESIZE(0, 4) + INFOSIZE; | 284 | return H48_TABLESIZE(0, 4) + INFOSIZE; |
| 285 | } | 285 | } |
| 286 | 286 | ||
| 287 | /* | ||
| 288 | TODO: the following function suffers from a big performance loss (about 40%) | ||
| 289 | because of all the mutex locking. It is possible to reduce the first lock | ||
| 290 | (at the beginning of the outermost for loop) by caching the next few items at | ||
| 291 | once and then looping over the cached elements. But for the second one (inner | ||
| 292 | loop) the access is non-sequential, so this cannot be done. | ||
| 293 | |||
| 294 | However, in both cases in theory we do not care if we are reading the old | ||
| 295 | value or the updated one. Depending on the compiler guarantees on concurrent | ||
| 296 | memory access, we may be fine just removing the locks altogether. | ||
| 297 | |||
| 298 | It is probably possible to solve part of this by using atomics. | ||
| 299 | */ | ||
| 287 | STATIC void * | 300 | STATIC void * |
| 288 | gendata_h48h0k4_runthread(void *arg) | 301 | gendata_h48h0k4_runthread(void *arg) |
| 289 | { | 302 | { |
