Multithreading, Multi core processors

[p.g.taboada]

Hi,

I could not find any information on this topic in the reference documentation. As multi-core processors are becoming usual even in a developer computer this topic could gain importance.

When developing with ejbs, architecture by restriction, we are supposed not to "multithread" ourselves - hence loosing security and transactional contextes could be the consequence. Believing the virtual maschine is going to do it all for is seems to be quite naive.

How is the spring framework positioned on this regard?

brgds,

Papick

[karldmoore]

I'm quite interested, what would you like to see in Spring to support multi processors?

[p.g.taboada]

Interesting question.

Well, first question is, what about Threadsafety? Where is Spring regarding multithreading: is it "works by accident" or "works by design".

If it is works by design, it would be interesting to have some insight here, like core stuff like BFs and so on.
Some of us are using Spring + other stuff to have a simpler enterprise development (sorry for the enterprise, but I think you know what I mean). Are there some best practices or restrictions like in the ejb world?

If I take one of mine small Spring + Hibernate + Struts/JSF/RCP/Whatsoever app - is it going to work on one of those multi-core machines without problems? Always assuming my code isn't doing any magic.

After that - will I take advantage of the system? There is a nice article "the free lunch is over", and in fact, it can be that one of my apps is not going to run in on a single 3Ghz machine anymore, but on a new 4x less then 3Ghz one.

Another point is really addressing the frameworks used by us spring users. Old ones like ORM tools, Quartz & Co. Spring solves api incompatibilities, makes simplifications (email, quartz), design flaws (exceptions in jdbc & co) and so on. Is thread safety an issue? New ones like hadoop - and there is terracota.

If I have some problem that would be best solved in parallel threads - are there DOs and DON'Ts concerning the framework, are there best practices? Spring is making stuff easier, here too?

Does this answer you question? :-)

Just to make it clear - I like Spring and I am not using anything else. I was happy to leave the architecture by restriction imposed by the j2ee ways and I enjoy the freedom of choice I have with spring.

[Alarmnummer]

Interesting question.

Well, first question is, what about Threadsafety? Where is Spring regarding multithreading: is it "works by accident" or "works by design".

I was working on a blog 'spring and visibility problems' regarding visibility problems in Spring based applications. A lot of beans wont have visibility problems in Java 5 because there is a 'happens before action' between the placement of the bean in a hashmap and the retrieval of a bean in a hashmap: so all changes made by the thread that placed the item in the hashmap are visible in the thread that read the bean from the hashmap.

My question is: is this good design or luck? I make my object threadsafe by design.

If I take one of mine small Spring + Hibernate + [quStruts/JSF/RCP/Whatsoever app - is it going to work on one of those multi-core machines without problems? Always assuming my code isn't doing any magic.

My guess is that visibility problems are going to appear in multicore machines and using Java 5 (the behaviour in Java 1.4 and older is 'undefined'). The new memory model (JSR133) makes perfectly clear what is allowed and what not. So I guess a lot of applications do stuff that is not allowed and this will lead to issues.

example, is this code threadsafe?:

class MyInt{
   private int value;

   public MyInt(int value){
      this.value = value;
   }

   public int getValue(){
       return value;
   }
}

If I have some problem that would be best solved in parallel threads - are there DOs and DON'Ts concerning the framework, are there best practices? Spring is making stuff easier, here too?

Hell yes I have written multiple applications that use a lot of (custom) multi threading and Spring is a dream to work with. I define what I what, and Spring makes it easy to do.

[Alarmnummer]

The post regarding spring and visibility problems can be found here:
http://blog.xebia.com/2007/03/01/spr...lity-problems/

[Andreas Senft]

Hmm. Peter, do you consider creating a Jira report concerning the concurrency issue of the singleton map you describe? Shouldn't be that hard to fix.

BTW: The book you recommend (Java concurrency in practice) is really a good read

Regards,
Andreas

[Alarmnummer]

Hmm. Peter, do you consider creating a Jira report concerning the concurrency issue of the singleton map you describe? Shouldn't be that hard to fix.

The 'cool' thing is that there is no problem in the code for standard singletons (under Java 5 and higher) because of the save handoff property.

BTW: The book you recommend (Java concurrency in practice) is really a good read

It is a very good book. Together with "Concurrent Programming in Java" it is my favorite java books about the subject.

[Andreas Senft]

The 'cool' thing is that there is no problem in the code for standard singletons (under Java 5 and higher) because of the save handoff property.

Yes, but what about Java 1.3 and 1.4?

[Alarmnummer]

Yes, but what about Java 1.3 and 1.4?

Undefined behavior. But because of the strong memory coherence most cpu's provide (write through caches, bus sniffing caches), it won't go wrong with todays cpu's (this says nothing about the future, and it also makes your Java code dependent on the hardware it is going to run on).

Spring can't do anything to make sure that beans work under older virtual machines. The only thing that can be done inside the Spring framework, is make the properties volatile. The same goes for setter based beans from spring-users. Another solution would be to use constructor-based DI in combination with final fields.

[Andreas Senft]

Spring can't do anything to make sure that beans work under older virtual machines. The only thing that can be done inside the Spring framework, is make the properties volatile. The same goes for setter based beans from spring-users. Another solution would be to use constructor-based DI in combination with final fields.

After re-reading the article more meticulous, I think you are right. Seems that my assumption to fix this kind of problem within Spring wasn't correct.

BTW: It is a fine article. Informative, and good to read.

Regards,
Andreas