Threading issues in PVAccess

[shroffk]

1d300d3#commitcomment-32935258

Matej pointed out, that in PR #9 there are a few instances where the synchronization was used not just on the collection operations but on blocks of code around it.

So...
I can add synchronized blocks back where they are needed.

However, It might still be good to consider the use of java synchronized collections as a way to simplify the code.

[msekoranja]

Simplified java synchronized collections are only good if you do simple operations on collections. Once you need to do a more-then-one operation as atomic, they do not work anymore (where not intended for that case).

The only thing that might looks non-standard are IntHashMap/ShortHashMap. They are there for performance reasons to avoid auto-boxing of type. I guess this is not a big deal and they can be replaces with standard collections - however syncrhonization must stay as it was.

[shroffk]

I put together a small performance test to compare the performance of the

Attemp 0 Added a 100000 entries to IntHashMap in :21 ms
Attemp 0 Added a 100000 entries to synchronized hash map in :23 ms

Attemp 0 Randomly read 100000 entries from IntHashMap in :56 ms
Attemp 0 Randomly read 100000 entries from synchronized map in :19 ms

[shroffk]

Simplified java synchronized collections are only good if you do simple operations on collections. Once you need to do a more-then-one operation as atomic, they do not work anymore (where not intended for that case).

Agreed, In the PR I see a few blocks where the synchronization was replaced. I will add the synchronization blocks back.

[shroffk]

closing it for the time being, the broader issue about synchronization will be added as individual tickets