Stack: want to replace it

Developers
2013-11-26
2013-11-27
  • Guus Bonnema
    Guus Bonnema
    2013-11-26

    Hi Paul,

    Before I leave for a while, want to update you on an intention I have of replacing the stack by a map. The reason is, there is no implementation of Stack<T> that performs as well as the ConcurrentMaps. In order to protect the stack, which is public for obvious reasons, I would have to make it synchronized, which is a lot slower and less scalable than ConcurrentHashMap is. I chose to deprecate it with the Map store as alternative.

    Let me know whether you agree. I plan on committing it tonight.

    Kind regards, Guus.

     
  • I don't believe there is any need to change it - although, based on my new (semi-)understanding of Java it should have been private - the only way of accessing it is by means of the push and pop services. Why did you think it "obvious" that it should be public?!

     
    Last edit: J. Paul Morrison 2013-11-27
    • Guus Bonnema
      Guus Bonnema
      2013-11-27

      On 27-11-13 01:50, J. Paul Morrison wrote:

      I don't believe there is any need to change it - although, based on
      new (semi-)understanding of Java it should have been private - the
      only way of accessing it is by means of the push and pop services. Why
      did you think it "obvious" that it should be public?!


      Stack: want to replace it
      https://sourceforge.net/p/flow-based-pgmg/discussion/121879/thread/69901eb6/?limit=25#03df


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/flow-based-pgmg/discussion/121879/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      I believe I talked too fast and it was late, and I was tired. What I should have
      said is that the stack should be published of course through push and
      pop. And that is where the stack needs synchronizing. I don't see any
      other way than using synchronizing on Stack, because the user component
      that is supposed to pop and push is a different thread.

      I do see a much better performing container, which is ConcurrentHashMap. This one needs no protection from our side and we can declare the container final. Pushing and popping will not require locking at all.
      This is by far the best performing solution that I can think of.

      On the other hand, the stack will require synchronize for the pop and push.

      I added the store variable as a ConcurrentHashMap beside the stack and
      added @deprecated to the stack. If you don't agree, I can revert. It
      accesses and store Packets using a key.

      Let me know what you think.

      Regards, Guus.

       
      Last edit: Guus Bonnema 2013-11-27
  • I still don't get it! push and pop are specific to one Component, each of which has its own Stack. These API calls are the only way to access this stack! It looks like you are looking at something quite different! I have no idea why you even feel they should be synchronized - one component's stack cannot interfere with another component's.

    I just noticed that you have deprecated push and pop - these are API calls for use by the components and CANNOT BE DEPRECATED! You have no idea whether people are using them out there!

    Guus, this is taking way too much of my time, and I am not convinced of its usefulness. I thought you were going to incrementally improve the product, but I am starting to get worried!

    I will be unable to access my computer for the rest of the day, but can send and receive email from time to time...

     
    Last edit: J. Paul Morrison 2013-11-27
  • Guus Bonnema
    Guus Bonnema
    2013-11-27

    hi Paul,

    I understand I crossed a line. I apologize and will revert the change.
    From now on I will focus on the locks, without changing source, just observing and querying.

    Kind regards, Guus.

     
  • Thanks, I would appreciate that!

    P.