I haven't every used read-only CASes and have no idea how they are implemented. ... or maybe I'm just failing to make the mental connection to something I remember by a different name.
Your explanation seems to imply that the classloader switch might somehow lead to some threads being able to modify the CAS and thus circumventing the read-onlyness? Cheers, -- Richard > On 18.08.2016, at 18:47, Marshall Schor <[email protected]> wrote: > > The Pear support was done before we contemplated read only CASes. > > Even though a CAS is read only, when you get Feature Structures (FSs) via > iterating, those FSs are made into Java cover class instances, according to a) > whether or not the JCas is being used, and if it is, b) what "set" of JCas > cover > classes is currently active. > > Within a Pear, there can be different definitions of some JCas cover classes. > The code "switches" the JCas set when crossing the Pear boundaries, as the > pipeline is executing. > > > This switching is not thread-safe. So (currently) a read-only CAS being > operated on by thread T1 containing a Pear would switch to use the Pear's JCas > definitions while perhaps another thread T2 not containing a pear, was > iterating. This would (currently) cause T2 to start getting JCas cover class > instances from the Pears's JCas definitions. > > Not sure how to proceed. On the one hand, we could keep Pear information on a > "per thread" basis in thread local data. This perhaps might slow things down > a > bit (not sure). On the other hand, we could "outlaw" the use of Pears in > read-only CAS situations (not sure how to detect this, though). > > It probably isn't a real problem (yet) because these are unusual ways to > operate; I'm guessing that the applications doing shared read-only CASes are > not > using Pears, and vice versa (so far). > > Opinions welcomed :-) -Marshall >
