| Concurrent readers impossible? [message #1843569] |
Sat, 07 August 2021 08:16  |
Eclipse User |
|
|
|
I (using jstack) observed a deadlock of two simple pairs of readOnly() invocations:
Thread T1 held a lock on resource R1 and requested a lock on resource R2.
Thread T2 held a lock on resource R2 and requested a lock on resource R1.
Classical deadlock, ok, BUT, all resource access happened through invoking XtextDocument.readOnly(), 3 out of 4 calls actually came via IReadAccess.tryReadOnly().
Call me naive, but I had assumed that several readers should not interfere with each other.
What's more, several methods involved are documented with statements like "Gets a read-only copy of the State ...". But in the implementation I can't see any copying near or far.
Are concurrent readers on a resource/document supposed to be working? Are there additional rules to be followed to make it work? Or is such concurrency outside the scope/design of Xtext?
FWIW, this is Xtext 2.22.0
|
|
|
|
|
|
|
|
| Re: Concurrent readers impossible? [message #1843689 is a reply to message #1843634] |
Fri, 13 August 2021 18:21  |
| Eclipse User |
|
|
|
Ed W., in my first post here, I wrote:
"Call me naive, but I had assumed that several readers should not interfere with each other."
I was just asking for clarification, on a matter, where my software engineer's intuition is at conflict with Xtext's method "readOnly()". So, I was naive. I learned the lesson by now.
It was Christian who suggested to file a github issue, the issue just being another channel for discussion, not presuming that Xtext is "wrong".
I could easily join in on the lament about the state of concurrency in Java, but I'm also ready to make do with what we have.
The real difficulty, as I see it, is that Eclipse and Xtext already contain so much control flow complexity and concurrency complexity that the poor little user code only needs to require one lock and we already have deadlock, as neither side knows which locks the other side my require or hold, nor can we rely on any rules what other work might be executing concurrently in which situation, nor do we know who calls me and when. If you are interested in why I believe that 75% of my deadlock is caused by Xtext, have a look at the github issue.
I guess all I'm saying: it really helps A LOT to get some background information about non-obvious aspects of the Xtext design. Even after 10 years of getting my hands dirty with it.
Stephan
PS: I still don't believe it's a good idea that ChangeSerializer spins the event loop ... (did you know it does??).
PPS: My current strategy to avoid the deadlock is: make my complex operation REALLY MODAL, switching as much as possible to single-thread mode, by locking both UI thread and the entire workspace :)
|
|
|
| Re: Concurrent readers impossible? [message #1843772 is a reply to message #1843689] |
Tue, 17 August 2021 07:19 |
| Eclipse User |
|
|
|
Hi Stephan
Sadly, lazy is good for efficiency but dreadful for concurrency ...
Ok. I think we're on the same page. My usage of Xtext has perhaps been simpler so that the simple one worker at a time rule has worked. My only experience of really bad things is that the builder is sometimes determined to do far far more work than necessary. Bugs are open but nobody seems minded to investigate. The code is obscure The problems seemingly intermittent. I've only recently discovered how to get past the conflicting signers lockout that prevents addition of instrumentation code to checked out Xtext projects. (There are some 'fragment' packages in the wrong plugins so you have to checkout more than you might expect.). Maybe I'll take another shot at it.
Regards
Ed
|
|
|
Powered by
FUDForum. Page generated in 0.03796 seconds
Home