Add Caching mechanism (#2547)

[dbinkele]

solves #2547

[alexanderpann]

Thanks for the addition! I just had a quick look:

• You have to somehow derive the JBR executable from

  mbeddr.core/build.gradle

  Line 14 in ee1a481

  downloadJbr {

  to not duplicate the logic.
• I really do not like seeing code for locking in our platform. It is so easy to use your API incorrectly. Can you implement is similar like here with a runnable parameter? I am not 100% sure, but I believe marking the boolean variable as volatile should also be enough.

btw, you can use new singleton() from the collections language.

[alexanderpann]

@dbinkele I didn't understand your code with the locking at all, it doesn't look right to me. I pushed a commit. Can you see if the change would be okay for you?

[dbinkele]

@dbinkele I didn't understand your code with the locking at all, it doesn't look right to me. I pushed a commit. Can you see if the change would be okay for you?

@alexanderpann This changes the semantics. The lock was there to make sure that Thread A is running in the 'withCachedLogicalChildren'-Environment and any Thread B who wants to do so as well must wait until A is finished. But both would do the caching. Now only does the caching, B starts without waiting and probably does no caching ....

[alexanderpann]

@dbinkele B does wait, I added another test case but I can't show a counter example where it doesn't work. The current thread blocks until it calls unlock. You can check the output of the second test. "Start" is called at a random time but "Inside" and "End" are always executed in order.