Code review for potential concurrency issues

Developers
2013-11-16
2013-11-17
  • Guus Bonnema
    Guus Bonnema
    2013-11-16

    Hi Paul,

    I started reviewing Network. There is a lot to be done in terms of making it threadsafe. Also, some of the synchronization is heavier than necessary. Furthermore, I suspect that since the development of JavaFBP, Java has evolved some nice extra concurrency features, like the ConcurrentHashMap and such. They have much better concurrency and scalability than a synchronized HashMap.

    What I checked in is not complete yet, but feel free to have a look. I only adjust other classes if they refer to Network.

    So far the status for today.

    Regards, Guus.

     
  • Hi Guus, I note that you have added an @Immutable annotation - at the Toronto Meetups we have started to try to tease out architectural issues from implementation detail, and some of the attendees zeroed in on "immutability" of IPs as an architectural requirement for true FBP. I protested that IPs can be changed, but they explained that the unique ownership rule means that one process cannot see IPs being changed by another process - I think I said that correctly! The term immutability was rephrased as "visible immutability" - I suggested "externally visible immutability", but the consensus seemed to be that "externally" didn't add much to our understanding! Does this make sense to you? Also, is this discussion at all relevant to the changes you are making to the code?

     
  • Guus Bonnema
    Guus Bonnema
    2013-11-17

    The annotation @Immutable is important for concurrency. It has a specific meaning to Java in relation to concurrency. It is not related to your IP discussion.

    I apologise up front for the following rant. Disregard if you don't like :)

    Requirements Engineering
    If immutability is a requirement for FBP, there must be a reason FBP requires immutability for IP's. Also, a requirement is incomplete as long as there are no acceptance criteria. Only if both are there, do you have a real requirement.

    Eliciting architectural requirements from implementations can help you discover requirements. You still need to verify that it really is an FBP requirement and not just an implementation requirement for a subset of FBP implementations.

    It is like reverse engineering a system and then turning around and saying all systems must work this way. The principle is flawed.

    Mutable IP's
    As far as IP's being immutable, I tend to agree with your initial stand where only one component can alter an IP: the owner. Maybe you could say that the IP should find no modification while in transport during the connection phase.

    However.

    The simple truth is that sending an IP across platforms could change the encoding: 1. from little endian to big endian, and 2. from ASCII or UNICODE to another coding that is relevant to a certain machine (like EBCDIC on mainframe). And what if the contents has no equivalent in the new encoding?

    The first thing you need to do is to define what immutable means (provided it really is an FBP requirement). Adding the adjective "visible" without having defined "immutable" properly, begs confusion. What does "visible immutably" mean, if "immutable" was not defined? What does "invisible immutably" mean? What does "visible mutably" mean?

    I fear that "visible immutability" creates misinterpretation. It does not have a strict definition in technical terms.

    FIXME:
    1. Find out if immutable IP's is really an FBP requirements, otherwise, just disregard it.
    2. Find the acceptance criteria.
    3. Concurrently: Define exactly what immutable IP means.

    After that, hopefully, you can leave out the adjective, visible.

    Hope this helps.

    Kind regards, Guus.

     
  • No problem - that was interesting!

    Higher up you stated, "Furthermore, I suspect that since the development of JavaFBP, Java has evolved some nice extra concurrency features, like the ConcurrentHashMap and such."

    Does this mean that JavaFBP is Java-release-dependent? Do we have to specify this dependency somewhere?

    Thanks, and best regards,

    Paul

     
  • Guus Bonnema
    Guus Bonnema
    2013-11-17

    In short : yes, we should.

    Running Java 4 and earlier will trash some of the current code. AFAIK we used code Java 5 at the moment.

    I will check and get back to you whether java 5 is sufficient.

    BTW, in linux all programs specify their dependencies, whichever libraries they use. If we were to package JavaFBP for linux, we would have to specify the dependencies in the package information.

    Apart from all that, it is just prudent to specify the dependencies.

    Kind regards, Guus.