STM Compiler: Transactional Contexts 2

STM Compiler: Transactional Contexts 2

I've worked out some details wrt "transactional contexts":
http://software.intel.com/en-us/forums/showpost.php?p=66296

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

All about lock-free algorithms, multicore, scalability, parallel computing and related topics: http://www.1024cores.net
2 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

Quoting - Dmitriy V'jukov

I've worked out some details wrt "transactional contexts":
http://software.intel.com/en-us/forums/showpost.php?p=66296

Here is more realistic and detailed proposal.

What it's all about?

It's about reducing overheads of full-fledged STM to that of distributed fine-grained locking, and at the same time preserving composability and absense dead-locks. Distributed in a sense that every object has it's own lock and no global state is touched.

I think that on some workloads transactional-context-powered-STM can completely blow plain-STM of the water.

All about lock-free algorithms, multicore, scalability, parallel computing and related topics: http://www.1024cores.net

Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi