Eclipse Community Forums: TMF (Xtext) » Concurrent readers impossible?

Help

Home

Home » Modeling » TMF (Xtext) » Concurrent readers impossible?

Show: Today's Messages :: Show Polls :: Message Navigator

Concurrent readers impossible? [message #1843569]

Sat, 07 August 2021 12:16

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

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

Report message to a moderator

Re: Concurrent readers impossible? [message #1843570 is a reply to message #1843569]

Sat, 07 August 2021 12:54

Ed Merks

Messages: 33252
Registered: July 2009

Senior Member

I expect the underlying issue is that is that even "reading" a model can involve resolving a proxy, which can demand load a new resource into the resource set which is effectively a write operation on the resource set's state...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Concurrent readers impossible? [message #1843571 is a reply to message #1843569]

Sat, 07 August 2021 12:54

Christian Dietrich

Messages: 14729
Registered: July 2009

Senior Member

can you open a github issues. i have doubts sebastian is still reading here

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Day Job: https://www.everest-systems.com

Report message to a moderator

Re: Concurrent readers impossible? [message #1843573 is a reply to message #1843570]

Sat, 07 August 2021 14:19

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Ed Merks wrote on Sat, 07 August 2021 14:54

I expect the underlying issue is that is that even "reading" a model can involve resolving a proxy, which can demand load a new resource into the resource set which is effectively a write operation on the resource set's state...

Quite likely (though quite surprising when you look at the API).

Report message to a moderator

Re: Concurrent readers impossible? [message #1843574 is a reply to message #1843571]

Sat, 07 August 2021 14:21

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Christian Dietrich wrote on Sat, 07 August 2021 14:54

can you open a github issues. i have doubts sebastian is still reading here

Sure: https://github.com/eclipse/xtext-core/issues/1731

Report message to a moderator

Re: Concurrent readers impossible? [message #1843634 is a reply to message #1843574]

Wed, 11 August 2021 12:18

Ed Willink

Messages: 7679
Registered: July 2009

Senior Member

Hi Stephan

Historically Java, in comparison to C++, did a pretty good job at adding OO polymorphism and GC so that both have pretty sound foundations. It also elevated the task library to seemingly friendly Thread/Runnable classes. However there is no underpinning foundation; just a clear but unsound API so that Java provides assembly-language-like capabilities for applications to multi-thread and synchronize but no ability to detect whether the result will be dead/live-lock free. Developers are left to code components that purport to be useful in a multi-threaded context only for users to discover that they don't always work.

The basic bags-it's-mine philosophy works well provided the duration of the lockout is short and the activities are simple enough to avoid transitive complexities. But as soon as an unwise lock is help trouble can ensue.

The EMF philosophy is particularly good. EMF is not thread-safe; it is an application responsibility. This has fallen down occasionally when the escalation to application level has been overlooked for live validation in an editor. Unfortunately seemingly simple activities such as eGet() can be very not-simple if for instance a UML model needs to perform the lazy load of a UML profile, or an OCL enriched Ecore model needs to perform the lazy creation of the OCL environment.

The Xtext philosophy of short sharp lockouts also works provided the user code is simple. But complex user code can easiy break the philosophy and there is little point raising an Xtext bug; it's probably a developer bug for failing to understand Java limitations and most certainly a Java bug for having such a fundamentally unsound capability. AFAIK there is no research able to make an ad hoc agglomeration of competing synchronizations sound.

IMHO the only way to design sound threading is from the system level down. A sound system design can decide when and how its sub-systems should communicate and provide appropriate communication channels. Sub-systems can then be tailored to comply with the system design, Sadly few components support such tailoring so the existence of a system design is very rare.

Instead we must rely on simple rules of thumb. e.g. for Eclipse all SWT activity must be on the UI thread; all long running activity must be on a Worker thread giving an obvious conflict in reporting back from the worker to the UI. Some diagnosis of rules of thumb violation is possible as when SWT throws its illegal thread access (with increasing frequency as we lose the developers who understood the original design).

For Xtext, things must be short. You as the developer must comply with the best endeavors of the Xtext rules of thumb. The bug is at the point where the conflicting lock was thoughtlessly acquired.

Regards

Ed Willink

Report message to a moderator

Re: Concurrent readers impossible? [message #1843689 is a reply to message #1843634]

Fri, 13 August 2021 22:21

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

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 :)

Report message to a moderator

Re: Concurrent readers impossible? [message #1843772 is a reply to message #1843689]

Tue, 17 August 2021 11:19

Ed Willink

Messages: 7679
Registered: July 2009

Senior Member

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

Report message to a moderator

Previous Topic:	Customize Java-Expression "toString"
Next Topic:	Xtend gradle builder leaves java files for deleted Xtend files behind

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Nov 09 02:15:30 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter