4 ms·

I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-saf

I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.

stcredzero 15y ago
I'm not if sure the author understands concurrency. EDIT: Author of the blog post.
- beersigns 15y ago
  I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own. EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
  - bad_user 15y ago
    The fix you're proposing is innadequate for a lot of instances. A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable. Also, threadsafe data-structures have terrible performance characteristics, unless the implementation is lockfree, and lockfree implementations are hard to get right. Therefore I don't blame devs that use HashMaps, as sometimes is better to put locks in other places, or to make sure that the variables are local to a thread. Threading is hard, lets go shopping.
    - hythloday 15y ago
      Just FYI, ConcurrentHashMap is indeed lockfree (although it's got a gargantuan memory footprint). Wrapping your HashMap with Collections.synchronizedMap gives you a blocking threadsafe HashMap.
      - runT1ME 15y ago
        ConcurrentHashMap is not lock free, it uses lock striping across multiple buckets.
        hythloday 15y ago
        I stand corrected.
    - brown9-2 15y ago
      Even without multithreading, mutating the value of a key (such that hashCode() changes) after putting it in the map entry won't return the same entry. This is a HashMap basic, not just something special jujitsu you need to learn with multithreading. I think blaming someone for using a non-thread-safe data structure without sufficient explicit locking is justifiable.
  - bermanoid 15y ago
    Magic fix: ConcurrentHashMap....better still write your own. I hope this is a joke. I know plenty of very good Java programmers, but only one or two that I would ever trust to write a concurrent hash map class that matched java.util.concurrent.ConcurrentHashMap's functionality (to say nothing of performance), let alone improve on it. It's a nasty chunk of code, it's not a simple matter to get this right: http://www.docjar.com/html/api/java/util/concurrent/ConcurrentHashMap.java.html http://www.docjar.com/html/api/java/util/concurrent/Concurre...
- aaronblohowiak 15y ago
  Author of Play or of the blog post?

I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.

stcredzero 15y ago

I'm not if sure the author understands concurrency. EDIT: Author of the blog post.

beersigns 15y ago
I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own. EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
- bad_user 15y ago
  The fix you're proposing is innadequate for a lot of instances. A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable. Also, threadsafe data-structures have terrible performance characteristics, unless the implementation is lockfree, and lockfree implementations are hard to get right. Therefore I don't blame devs that use HashMaps, as sometimes is better to put locks in other places, or to make sure that the variables are local to a thread. Threading is hard, lets go shopping.
  - hythloday 15y ago
    Just FYI, ConcurrentHashMap is indeed lockfree (although it's got a gargantuan memory footprint). Wrapping your HashMap with Collections.synchronizedMap gives you a blocking threadsafe HashMap.
    - runT1ME 15y ago
      ConcurrentHashMap is not lock free, it uses lock striping across multiple buckets.
      - hythloday 15y ago
        I stand corrected.
  - brown9-2 15y ago
    Even without multithreading, mutating the value of a key (such that hashCode() changes) after putting it in the map entry won't return the same entry. This is a HashMap basic, not just something special jujitsu you need to learn with multithreading. I think blaming someone for using a non-thread-safe data structure without sufficient explicit locking is justifiable.
- bermanoid 15y ago
  Magic fix: ConcurrentHashMap....better still write your own. I hope this is a joke. I know plenty of very good Java programmers, but only one or two that I would ever trust to write a concurrent hash map class that matched java.util.concurrent.ConcurrentHashMap's functionality (to say nothing of performance), let alone improve on it. It's a nasty chunk of code, it's not a simple matter to get this right: http://www.docjar.com/html/api/java/util/concurrent/ConcurrentHashMap.java.html http://www.docjar.com/html/api/java/util/concurrent/Concurre...
aaronblohowiak 15y ago
Author of Play or of the blog post?