Lock-free and wait-free concurrency

[David Van Couvering <Da...@Sun.COM>]

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

[scott hutinger <sr...@www.mprojects.Horrabin.wiu.edu>]

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
>
>

Re: Lock-free and wait-free concurrency

[scott hutinger <sr...@www.mprojects.Horrabin.wiu.edu>]

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

[Jeremy Boynes <jb...@apache.org>]

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