The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (McKown, John) writes: > This is not from IBM or about mainframes. But I think it will be of > interest to the readers here. It is from Sun about "Transactional > Memory" and how that it can be used to more easily implement > threadsafeness and multiprocessors. > > <quote> > Transactional memory appears to be the key to unlocking the full > potential of next-generation chip multiprocessing (CMP) technologies and > accelerating both their performance and their adoption. It could also be > a core enabling technology for the massively powerful terascale and > petascale computing systems now on the drawing boards of advanced > research labs and government agencies. Why? Because transactional memory > can solve a very serious problem in software engineering-a problem that > is severely constraining application performance and draining countless > productive hours from skilled programmers. > </quote> > > http://research.sun.com/spotlight/2007/2007-08-13_transactional_memory.html 801/risc had "transactional memory" ... and was used in a kind of DBMS implementation under CPr. I have some vaque recollections about CPr having discussions with system/r people (original relational/sql done on vm370 platform) http://www.garlic.com/~lynn/subtopic.html#systemr 801 transactional memory was used in aix v3 to implement the journaled file system (JFS) ... collecting all the unix filesystem metadata in a "transaction memory" area ... and using it to capture metadata changes for journal/logging. misc. past posts mentioning 801, romp, rios, somerset, power, power/pc fort knox, etc http://www.garlic.com/~lynn/subtopic.html#801 there has been ongoing discussions about lack of an easily understood and useable parallel programming paradigm .... which has been a (unsuccesful) "holy grail" for a couple decades ... but is becoming much more critical with the growing pervasiveness of multi-core chips ... and paradigm shift that chips haven't been getting significantly faster ... and thruput increases only coming from being able to do more operations in parallel http://www.garlic.com/~lynn/2008k.html#63 Intel: an expensive many-core future is ahead of us misc older posts mentioning transactional memory http://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"? http://www.garlic.com/~lynn/2005r.html#27 transactional memory question http://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism? http://www.garlic.com/~lynn/2007n.html#6 Is Parallel Programming Just Too Hard? http://www.garlic.com/~lynn/2007n.html#36 How to flush data most efficiently from memory to disk when db checkpoint? http://www.garlic.com/~lynn/2007o.html#12 more transactional memory for mutlithread/multiprocessor operation http://www.garlic.com/~lynn/2008d.html#50 CPU time differences for the same job http://www.garlic.com/~lynn/2008e.html#10 Kernels http://www.garlic.com/~lynn/2008h.html#27 Two views of Microkernels (Re: Kernels -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
