Originally posted by: Michael_Wong
Hi, all. I came back from BoostCon2010:
http://www.boostcon.com/program#schedulewhere I delivered three talks and participated in a panel discussion on Transactional Memory, along with such luminaries as Maurice Herlihy (the father of TM), Mark Moir (Sun), and Tatiana Shpeisman, with whom I have worked with for 2 years on the Draft Specification for C++ Transactional Memory.
I gave an update of C++0x, outlining the new schedule for a Final Committee Draft that was voted in at Pittsburgh:
http://www.filetolink.com/a33a3b47The talks on C+0x Concurrency
http://www.filetolink.com/06c4fa2dwas well attended by about 60 people and many clearly were also experts as they asked insightful questions and kept me on my toes. I was thankful that I was able to answer many of the questions.
As I was talking, I went over Clause 29 of N3092 which is our FCD.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdfSebastien Redl and others from the audience noticed a number of editorial problems in the Atomics Operations clause, which we will submit as a National Body Comment.
Three other questions were asked at the talk for which I asked Lawrecne Crowl, and here is his answer:
1. Would it be desirableto change ATOMIC_FLAG_INIT to STD_ATOMIC_FLAG_INIT.?
It already seems pretty long and the other macros all start with ATOMIC.
2. Can the result of is_lock_free() return a different value over
time (I know they can change per iinstance)? But we though may
be i you ahve a distributed architecture, then is_lock_free()
may be different over time.
We later changed the definition to require lock_free to be consistent across objects.
The function atomic_is_lock_free (29.6) indicates whether the
object is lock-free. In any given program execution, the result
of the lock-free query shall be consistent for all pointers of
the same type.
The problem was that you need to test before you allocate.
3. Can compilers diagnose misuse of atomic types in a lock-free
contexts when a type isn't lock free for a given platform?
I think compiler can only know when it might not be lock-free,
which would probably be sufficient. All the locking operations will
likely be in a dynamic library that gets overridden to lock-free
operations on platforms that support them.
Lawrence Crowl
Wednesday brought with it a special Transactional Memory (TM) day organized by Justin Gottschlich whom I met last year, and is doing some interesting work on releasing a TM library for Boost.
http://www.filetolink.com/161ee80d
The keynote from Maurice Herlihy, gave a world-wind tour of Transactional Memory today. He highlighted the key papers of the last decade which has lead to the recent growth in TM.
http://prezi.com/3rnocqymnf84/tmtoday
He described the usual issues with synchronization overhead, privatization, lock elision, the Gartner fad cycle, while drawing a closer look the reason for some of the most vocal proponent and opponent of TM. It ended with a delivery by each of Sun, IBM and Intel on their TM offerings. I chose to spend my part talking about the different nature of the TM runtime which can be configured:
http://www.filetolink.com/0bb6fdb4
This was followed by a panel discussion where I joined with Maurice Herlihy, Mark Moir from Sun/Oracle, and Tatiana Shpeisman from Intel to describe our view of the future of TM. The panel got very lively on one topic, which was what is the one thing that TM would need in the next 2 years.
Almost everyone agree that it would have to be some kind of application conversion to TM, or using TM. It was not clear whether converting an existing application to TM would actually yield any significant benefit given that TM still has problems in several areas of common usage idiom as compared to such usage in locks. Some common cases that TM don't do well are IO, locks, dynamic libraries, or even time delays. (Imagine a time delay in an atomic transaction). These are common usage idioms inside locks today. Here is a list from Paul McKenney outlining these issues:
http://paulmck.livejournal.com/13841.html
Until TM can come up with a way to deal with these common usage idioms used today in locks, any conversion to TM will meet with the difficulties that the conversion to TxLinux met, where the they converted only some cases of locks to TM, but others had to be left as locks.
This means that TM, as some researcher suggest may be relegated to a narrowly defined domain where code does not use any such questionable operations. This is not an unappealing answer either, and it certainly simplifies the unrealistic expectation placed on TM.
As part of this TM day, we also unveiled the first public talk on the Draft Transactional Memory Specification, given by Tatiana Shpeisman of Intel.
As usual BoostCon is full of talks that opens your eyes on the possibility of C++ and Boost. Last year, I had suggested that there should be a special parallel programming day for Boost, and Justin made that a possibility. Good work Justin and thanks for inviting Maurice Herlihy, who is a fantastic guest and speaker.
As I look back, I can see the potential of Boost becoming the premier C++ Conference. It is now not just about Boost, as we are looking at all things C++, including what is coming for C++ in terms of 0x and TM. In is not hard to see a future where people will get even more from BoostCon beside Boost. I know a segment of the Boost Community is resisting that, and I don't blame them. Right now, the size as some would say is just right to have a community feel. But others would argue for expansion and growth, and the benefit that would be derived from such growth.
As usual, I always want to go to as many talks as I can because BoostCon is not just about learning, but reconnecting with people who are active in the C++ community. I saw Marshall Clow whose company was generous enough to provided some sponsorship (I heard), Nevin Lieber, Stepen Lavavej, my good friend Christophe Henry whom I hung out with afterward on a visit to a few National Park, the wonderfully funny Jeff Garland, the incredibly informative Doug Gregor, and of course the wonderful and knowledgeable Joel de Guzman, and Hartmut kaiser. New people I met including Dean Michael Berris whose blog I read from afar , and Robert Ramey because we have been working on his Serialization Library. And of course, we must not forget thanking David Abraham for being instrumental in starting such a conference as BoostCon.
I went to Eric Lieber's Proto talk and continue to marvel at the simplicity that allows C++ to be a Domain Specific Embedded language to be used by other DSELs. I thought he was a powerful speaker. He helped us with some of our Proto tests. Another good speaker is Michael Caisse who talked about Spirit, Karma, and Qi, all built upon Proto. I was intrigued by Joel Falcou's (aka Crazy Frenchmen:) Numeric Template library which uses IBM's PowerPC Hardware and others to build a Fortran-like array library using templates. This fills a niche that I find many high-performance users are looking for as they move from Fortran to C++, which is a lack of a drop-in replacement for the Fortran array syntax in C++ (Vectors still doesn't quite do it). Currently, it uses G++ on PPC (as well as a number of other hardware/compiler combination) but I would be eager to try it out with our xlC++ compiler when that library is released on Boost. They were not the only people who use IBM's PPC that I encountered and frankly the number of IBM customers I get to meet here makes this trip extremely gratifying. As usual, I can't say who they are, but you know who you are and thank-you for coming up and saying hello afterward.
Delivering three talks and being part of an Expert Panel was a bit much and made me less able to enjoy BoostCon thoroughly by attending others talks this year as I did before. However, the reaction I got was terrific and this continues to urge me to give more to the community.