Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
May 27, 2017, 10:43:28 AM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
Pages: [1]
Print
Author Topic: Why doesnt this port use concurrentHashMaps?  (Read 6737 times)
jason
Jr. Member
**
Posts: 13


View Profile
« on: January 29, 2010, 12:26:57 AM »

Hi, I'm wondering why this port doesnt use ConcurrentHashMaps instead of HashMap+synchronized block?

for example in the Facade.getInstance method, its synchronized which has gotta be bad for performance
since its a commonly accessed method.
also, why does it bother to generate a "new Facade(key)" if one isnt provided? if it hasnt been subclassed then the app cant be using puremvc as its intended, and if it has been subclassed then creating this new Facade is a waste of effort.

at any rate to keep existing functionality, wouldn't replacing the instanceMap with a concurrenthashmap and reworking the method something like this make sense?
   
public static Facade getInstance(String key )
if (key== null) {
            throw new Exception("key cannot be null.");
        }

 Facade facade, newVal;
    do {
      facade= instanceMap.get(name);
      newVal = (facade== null) ? new Facade(key):facade;
    } while (!instanceMap.replace(name, facade, newVal));

        return newVal;
    }
}


Cheers

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2866



View Profile WWW
« Reply #1 on: January 29, 2010, 09:21:03 AM »

Thanks for pointing this out Jason. Certainly seems like ConcurrentHashMap would be attractive in this situation. However you do have to be extremely careful with its use, it's not as simple as replacing HashMap with ConcurrentHashMap and removing the syncrhonized block. Check out this article on the subject:

http://dmy999.com/article/34/correct-use-of-concurrenthashmap

Anthony, what do you think?
-=Cliff>
Logged
jason
Jr. Member
**
Posts: 13


View Profile
« Reply #2 on: January 31, 2010, 05:16:51 PM »


read to the comments at the bottom of the article. cchashMap is safe and works as intended.
it wont fix other problems in your code though of course.
My point here is that the current version blocks unnecessarily, and is also trying to do something that doesn't make any sense. perhaps it should be restructured such that it really is a factory?

incidentally, methods such as  Facade.removeCore are not threadsafe at all, as they are modifying an unmanaged hashmap.

same applies for the controller, model and view classes too!.

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2866



View Profile WWW
« Reply #3 on: February 01, 2010, 08:32:23 AM »

Agreed. Anthony, would you care to look into this?

-=Cliff>
Logged
aquinault
Moderator
Jr. Member
*****
Posts: 10


View Profile Email
« Reply #4 on: February 10, 2010, 03:34:05 AM »

This port doesnt use ConcurrentHashMaps instead of HashMap+synchronized because PureMVC Multicore is GWT compliant.
GWT includes a library that emulates a subset of the Java runtime library and this library doesn't have
java.util.concurrent.ConcurrentHashMap

Thanks Jason, effectively, methods such as Facade.removeCore are not threadsafe and i have to release a new version with correct code.

Anthony.
Logged
jason
Jr. Member
**
Posts: 13


View Profile
« Reply #5 on: March 02, 2010, 11:48:04 PM »

if the new 'threadsafe' code is blocking though it would be a real shame.
perhaps you need to use the Map interface only, and allow a mechanism for selecting the correct runtime
wiring (GWT, or jvm1.5+) .
alternatively has anyone tried retroweaver for converting modern java bytecode to java 1.4 compat bytecode? ref:http://retroweaver.sourceforge.net (I havent, no idea if it would work)
if it worked you could just add this as a secondary post build target to generate a gwt compatible variant.

Logged
Pages: [1]
Print
Jump to: