-
Notifications
You must be signed in to change notification settings - Fork 3.4k
[Swift] Changes to Mutex-es to guard the staticly shared [DFA] #3276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
By sharing the mutex in the same way as the DFA array it becomes possible to run in parallel Added a test in ThreadingTests Fixes: 3271 Signed-off-by: Martin van Wingerden <martin@martinvw.nl>
Hi, this sounds useful but I'm not sure your test is 'hungry' enough to prove that it works. |
Without my changes this test always fails and with it always succeeds. I do believe we should aim for a bit more code coverage but I doubt that multiple or much more complex grammar is needed, however a longer text of course make sense. I do not completely understand the second part of your comment, I might need a hint about that one. Thanks for your time! |
The reason a mutex is required is because originally the DFA is empty and gets populated gradually as the runtimes bumps into new grammar fragments. No mutex is required for reading.
Since the current test always parses the same expression, the DFA only gets populated once with a single exception where 2 threads are populating it the same way at the same time (which you seem ti have encountered)
In real situations It’s much more likely that 2 threads will populate it in different ways, thus going through slightly different code paths, hence my ask that you use longer and different expressions
Envoyé de mon iPhone
… Le 25 sept. 2021 à 13:24, Martin van Wingerden ***@***.***> a écrit :
Without my changes this test always fails and with it always succeeds. I do believe we should aim for a bit more code coverage but I doubt that multiple or much more complex grammar is needed, however a longer text of course make sense.
I do not completely understand the second part of your comment, I might need a hint about that one.
Thanks for your time!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Thanks for the explanation!
That makes a lot of sense, thanks for insight. I’ll try to look into it
later this week.
Could you also shed some light on when the ParserATNSimulator code path is
triggered? I do believe my current tests might not cover this as well.
|
Signed-off-by: Martin van Wingerden <martin@martinvw.nl>
@ericvergnaud I updated the test with a bit more complex expressions, do you think this would be enough: antlr4/runtime/Swift/Tests/Antlr4Tests/ThreadingTests.swift Lines 16 to 38 in 9f07205
I checked the call trace and I see that we actually touch all the changed files with the current test, so that looks good. EDIT: I checked instead of check, so it is already done. |
Signed-off-by: Martin van Wingerden <martin@martinvw.nl>
Signed-off-by: Martin van Wingerden <martin@martinvw.nl>
@parrt blessed, the failing test is unrelated and is fixed through another PR |
Thanks! |
Request for review: @janyou, @ewanmellor, @hanjoes, @rmehta33
By sharing the mutex in the same way as the DFA array it becomes possible to run in parallel
Fixes #3271