Summary: | Data races in BLAS static initialization | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Eigen | Reporter: | Benoit Jacob <jacob.benoit.1> | ||||||
Component: | General | Assignee: | Nobody <eigen.nobody> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Unknown | CC: | chtz, gael.guennebaud, jacob.benoit.1 | ||||||
Priority: | Normal | ||||||||
Version: | 3.3 (current stable) | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 558 | ||||||||
Attachments: |
|
Description
Benoit Jacob
2016-01-25 18:26:44 UTC
Note: this was discovered by Ury Zhilinsky at Google using Thread Sanitizer. Actually, seeing how simple the initialization code is, we have alternatives: 1) Do not use a helper constructor, just initialize those static arrays of pointer-sized constants. 2) Do not even use static variables at all. The cost of writing a few pointer values is probably negligible. Seeing how it's being used, how about 3) drop the tables of function pointers and instead use a switch statement on the code. I'd go with either 1) or 3), but for 3) I'd check the performance on small matrices. So if you prefer 3), first fix gemm only and I'll check (I already have a suitable and reliable benchmark for that). Created attachment 647 [details]
Fix blas static initialization race
Here's my patch following option 1), just plain static const array of function pointers. Passes blas/testing.
Created attachment 648 [details]
Fix blas static initialization race
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1152. |