On 8/24/2015 10:02 AM, Peter Klügl wrote: > Ok, thanks. I need to study the code some more... > > Do you have any advice for me what could have went wrong when I get > wrong values for this method in the debugger in a single thread scenario? I've debugged this (in Eclipse, using Oracle or IBM Java), without an issue... so I don't know what might have gone wrong in your case - you're not using some other Java by any chance?
-Marshall > > Best, > > Peter > > > Am 24.08.2015 um 15:18 schrieb Marshall Schor: >> To find out who's worked on a particular class, you can use SVN - in eclipse, >> right click the class, and do team -> show history. >> >> The getReserve() method is supposed to either get the JCas cover class from >> the >> map, or (if it doesn't exist) it's supposed to "reserve" the slot where the >> JCas >> cover class would be (were it in the table). The caller, if it gets "not >> found" >> is supposed to generate the JCas cover class and do a "put" to add it to the >> hash map. The "reserve" is there to cause any multi-threaded access to the >> identical FeatureStructure to pause while the "winner" of the getReserve >> reserve >> action finishes creating the JCas cover class instance and adding it to the >> table. (There's one JCas cover class per CAS, regardless of how many threads >> might be trying to access it - this multithreading support was put in some >> time >> ago to support multiple threads doing read actions on a (read-only) CAS). >> >> -Marshall >> >> On 8/24/2015 6:31 AM, Peter Klügl wrote: >>> Hi, >>> >>> I currently try to learn a bit about UIMA's internal JCas cover >>> class/object management in the context of UIMA-4568. When I try to debug >>> JCasHashMapSubMap.getReserve() I get different results compared to a >>> normal run. Each time a slot is reserved. >>> >>> Can someone of those who know about UIMA internals comment on that? >>> Advices and comments on UIMA-4568 in general are of course also welcome :-) >>> >>> Best, >>> >>> Peter >>> >
