Hi Thomas, > > Hi Lipeng, > > > May I know any comment or concern on this patch, thanks for your time > > 😄 > > Thanks for your patience in getting this reviewed. > > A few remarks / questions. > > Which strategy is used in this implementation, read-preferring or write- > preferring? And if read-preferring is used, is there a danger of deadlock if > people do unreasonable things? > Maybe you could explain that, also in a comment in the code. >
Yes, the implementation use the read-preferring strategy, and comments in code. When adding the test cases, I didn’t meet the situation which may cause the deadlock. Maybe you can give more guidance about that. > Can you add some sort of torture test case(s) which does a lot of > opening/closing/reading/writing, possibly with asynchronous I/O and/or > pthreads, to catch possible problems? If there is a system dependency or > some race condition, chances are that regression testers will catch this. > Sure, as your comments, in the patch V6, I added 3 test cases with OpenMP to test different cases in concurrency respectively: 1. find and create unit very frequently to stress read lock and write lock. 2. only access the unit which exist in cache to stress read lock. 3. access the same unit in concurrency. For the third test case, it also help to find a bug: When unit can't be found in cache nor unit list in read phase, then threads will try to acquire write lock to insert the same unit, this will cause duplicate key error. To fix this bug, I get the unit from unit list once again before insert in write lock. More details you can refer the patch v6. > With this, the libgfortran parts are OK, unless somebody else has more > comments, so give this a couple of days. I cannot approve the libgcc parts, > that would be somebody else (Jakub?) > > Best regards > > Thomas > Best Regards, Lipeng Zhu
