Lock-free and wait-free concurrency
I was looking to see if "++" was atomic (as I suspected it's not) and I found this very interesting article from the Blue Guys about java.util.concurrent.atomic in JDK 1.5. I am not an expert in locking, but this looked very interesting. Has anybody looked at this? Could Derby take advantage of this? http://www-106.ibm.com/developerworks/java/library/j-jtp11234/ David
Re: Lock-free and wait-free concurrency
David Van Couvering wrote: I was looking to see if "++" was atomic (as I suspected it's not) and I found this very interesting article from the Blue Guys about java.util.concurrent.atomic in JDK 1.5. I am not an expert in locking, but this looked very interesting. Has anybody looked at this? Could Derby take advantage of this? http://www-106.ibm.com/developerworks/java/library/j-jtp11234/ David I think there is a lot of stuff in j.u.concurrent that Derby could use, if only we could get a 1.5 version going ;-) With the 1.1 J2ME profiles that support the 1.4 APIs now in PFD perhaps we should look at the platform roadmap going forward. Perhaps a split would be appropriate between a platform for embedded devices (based on CDC 1.1 and JSR-169) with little concurrent access and limited resources and multi-user standalone/J2EE servers (based on 1.5) optimized for high concurrent access with unconstrained resources. -- Jeremy
Re: Lock-free and wait-free concurrency
Jeremy Boynes wrote: David Van Couvering wrote: I was looking to see if "++" was atomic (as I suspected it's not) and I found this very interesting article from the Blue Guys about java.util.concurrent.atomic in JDK 1.5. I am not an expert in locking, but this looked very interesting. Has anybody looked at this? Could Derby take advantage of this? http://www-106.ibm.com/developerworks/java/library/j-jtp11234/ David I think there is a lot of stuff in j.u.concurrent that Derby could use, if only we could get a 1.5 version going ;-) With the 1.1 J2ME profiles that support the 1.4 APIs now in PFD perhaps we should look at the platform roadmap going forward. Perhaps a split would be appropriate between a platform for embedded devices (based on CDC 1.1 and JSR-169) with little concurrent access and limited resources and multi-user standalone/J2EE servers (based on 1.5) optimized for high concurrent access with unconstrained resources. -- Jeremy (just an alternative view of things (fluff)) I was just thinking about this whole thing based on the VM versions/J2ME etc. I was a bit worried about what complexities are induced by moving forward and keeping older code from getting bit-rot etc. A big portion of this is related to architectures that are not supported in some type of easy to download VM. Currently Derby is running without problems on a Zaurus C3000 (4gig hard drive); although somewhat low on resources, I wouldn't call it starved. But, most of the embedded devices are of a processor nature that are not fully supported by some of the larger 'units' in the industry. But J2ME solves a lot of those problems. I hate to harp on the subject, but getting newer alternative processor VM's up and running are person resource dependent with the newer vm's past 1.3. Now, what are the differences between J2ME and a non-hotspot/jit VM of 1.3.x? I say anything that has a jit or hotspot starts to take over anything else. Although if one is resource lean, then what are the trade-offs for the jit? Smart jit, major jit, jit hotspots, jit what? (J2ME looks like it has some nice controls on fine tuning this). The line here is getting to the point of what can people currently get for a VM on a strange processor that people can really use now. I diverge (normal). The point of all this is I don't have a clue about the architecture of Derby. It needs to move forward without too many constraints on backward compatibility. But from the other point of view, it's nice to have a code base still intact that older VM's can use. BTW, the article is nice; but I thought atomic was all that existed in the world :-) I haven't followed the complete thought processes of how older VM's are going to reach EOL (end of life cycle). Perhaps the xbox will create some handhelds that are ppc related... It would be nice to have a bit more facts on J2ME/derby/jitted methods/ and resource needs etc. But that would be a future project. scott
Re: Lock-free and wait-free concurrency
scott hutinger wrote: Jeremy Boynes wrote: David Van Couvering wrote: I was looking to see if "++" was atomic (as I suspected it's not) and I found this very interesting article from the Blue Guys about java.util.concurrent.atomic in JDK 1.5. I am not an expert in locking, but this looked very interesting. Has anybody looked at this? Could Derby take advantage of this? http://www-106.ibm.com/developerworks/java/library/j-jtp11234/ David I think there is a lot of stuff in j.u.concurrent that Derby could use, if only we could get a 1.5 version going ;-) With the 1.1 J2ME profiles that support the 1.4 APIs now in PFD perhaps we should look at the platform roadmap going forward. Perhaps a split would be appropriate between a platform for embedded devices (based on CDC 1.1 and JSR-169) with little concurrent access and limited resources and multi-user standalone/J2EE servers (based on 1.5) optimized for high concurrent access with unconstrained resources. -- Jeremy One more fluff. If your going to do any type of 'embedded' type of work with something such as derby, then you really need the jit source code, plus the rest of the code. I don't see a jit off-the-shelf giving enough information about everything needed (although I very well could be wrong, often I am). Something the size of derby needs to have a bunch of 'extra' inclusions of code for getting needed information with some possible additions. Of course, every architecture is different, but I think after getting one architecture down with some fairly good conclusions on useage, that others could follow (somewhat) closely. I think the useage differences of users also create the need of jit source. scott (just an alternative view of things (fluff)) I was just thinking about this whole thing based on the VM versions/J2ME etc. I was a bit worried about what complexities are induced by moving forward and keeping older code from getting bit-rot etc. A big portion of this is related to architectures that are not supported in some type of easy to download VM. Currently Derby is running without problems on a Zaurus C3000 (4gig hard drive); although somewhat low on resources, I wouldn't call it starved. But, most of the embedded devices are of a processor nature that are not fully supported by some of the larger 'units' in the industry. But J2ME solves a lot of those problems. I hate to harp on the subject, but getting newer alternative processor VM's up and running are person resource dependent with the newer vm's past 1.3. Now, what are the differences between J2ME and a non-hotspot/jit VM of 1.3.x? I say anything that has a jit or hotspot starts to take over anything else. Although if one is resource lean, then what are the trade-offs for the jit? Smart jit, major jit, jit hotspots, jit what? (J2ME looks like it has some nice controls on fine tuning this). The line here is getting to the point of what can people currently get for a VM on a strange processor that people can really use now. I diverge (normal). The point of all this is I don't have a clue about the architecture of Derby. It needs to move forward without too many constraints on backward compatibility. But from the other point of view, it's nice to have a code base still intact that older VM's can use. BTW, the article is nice; but I thought atomic was all that existed in the world :-) I haven't followed the complete thought processes of how older VM's are going to reach EOL (end of life cycle). Perhaps the xbox will create some handhelds that are ppc related... It would be nice to have a bit more facts on J2ME/derby/jitted methods/ and resource needs etc. But that would be a future project. scott
