Intel® Software Network

I've worked out some details wrt "transactional contexts":
http://software.intel.com/en-us/forums/whatif-alpha-software/topic/60873/reply/64582/

Here is more realistic and detailed proposal.
User marks some classes with special declarator:

__declspec(tm_context)
class queue {
public:
void push(void* item) {
tm_atomic {
// implementation
}
}

void* pop() {
tm_atomic {
// implementation
}
}

// other member functions

private:
// some data
};

Compiler emits hidden rw-mutex member into all objects of such class. It is legal for non-POD types (or for non 'standard layout' classes in terms of C++0x). Two versions of member functions are generated: first is instrumented for transactional execution, second is not instrumented.
Compiler also checks following things. For every member function (which contains tm_atomic blocks) compiler checks whether this functions accesses only function parameters and private members of the class (possibly also some special functions like malloc/new). Also compiler checks whether pointers to those private members are taken.

1. If transaction on such object is outer-most transaction, then transaction locks hidden rw-mutex member in exclusive mode. Then transaction executes non-instrumented version of function, no wait for quiescence is required, no accesses to global meta-data.
2. If transaction on such object is not outer-most transaction, then transaction locks hidden rw-mutex member in shared mode. Then transaction executes as usual, i.e. instrumented version of function is executed.

If member function of the class accesses "global" data or pointers to private members are taken, then this function executes in "transactional" mode (variant 2). So single class can contain both "exclusive" functions (variant 1) and "transactional" functions.

If there are abort statements in "exclusive" functions, then function must be instrumented and executed in "serial atomic" mode.

Ok, this is the main part. However many details still have to be defined (the main detail is profitability). And also many improvements on this are possible. For example, if compiler sees following code:

queue q1, q2;
tm_atomic
{
void* v = q1.pop();
q2.push(v);
}

Compiler can still try to execute pop() and push() in "exclusive" mode:

1. lock in execlusive mode q1's mutex
2. execute q1.pop() in "serial atomic" mode (so that it will be possible to rollback it)
3. try lock in exclusive mode q2's mutex, if failed rollback step 2 and goto step 1
4. execute q2.push() in non-instrumented mode
5. unlock both mutexes

Hmmm... Though it already looks more like space shuttle science...