[thread] Is there interest in shared_lock_prioritized?
Hi, I've got a very basic implementation and tests of shared_lock_prioritized, that can be used like that: // Events are written down in order of // their execution in different threads shared_lock_prioritized<2 /*priorities count*/ > lock; // thread #1 // Lock with minimal priority lock_shared(); // thread #2 // Lock with minimal priority lock_shared(0); // thread #3 // Lock for writing with priority // greater than locks of threads 1 and 2 // Waits till already acquired locks in #1 and #2 finish // and then writes lock(1); // thread #4 // Will wait till thread #3 finishes, only then acquire lock lock_shared(0); Such shared lock gives us ability to manage order/priority of different lock attempts, we can make write locks have bigger priority that read locks, have multiple priorities writes (ordered write locks) and so on... Is there an interest in it? -- Best regards, Antony Polukhin
Le 20/02/13 07:00, Antony Polukhin a écrit :
Hi,
I've got a very basic implementation and tests of shared_lock_prioritized, that can be used like that:
// Events are written down in order of // their execution in different threads
shared_lock_prioritized<2 /*priorities count*/ > lock;
// thread #1 // Lock with minimal priority lock_shared();
// thread #2 // Lock with minimal priority lock_shared(0);
// thread #3 // Lock for writing with priority // greater than locks of threads 1 and 2 // Waits till already acquired locks in #1 and #2 finish // and then writes lock(1);
// thread #4 // Will wait till thread #3 finishes, only then acquire lock lock_shared(0);
Such shared lock gives us ability to manage order/priority of different lock attempts, we can make write locks have bigger priority that read locks, have multiple priorities writes (ordered write locks) and so on...
Is there an interest in it? Hi,
Fredrik Orderud is working on a templated version (See [Threads-devel] Extend shared_mutex with support for priority policies?) "shared_pri_mutex" with support for the following prioritization policies: UNSPECIFIED_PRIORITY, EXCLUSIVE_PRIORITY and SHARED_PRIORITY." IIUC, your approach is dynamic, that is, it the user that choose the priority while locking, while IIRC his approach is static, that is, the priority is given by the type of mutex, preserving in this way the boost::shared_mutex interface. Best, Vicente
2013/2/20 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
Fredrik Orderud is working on a templated version (See [Threads-devel] Extend shared_mutex with support for priority policies?) "shared_pri_mutex" with support for the following prioritization policies: UNSPECIFIED_PRIORITY, EXCLUSIVE_PRIORITY and SHARED_PRIORITY."
IIUC, your approach is dynamic, that is, it the user that choose the priority while locking, while IIRC his approach is static, that is, the priority is given by the type of mutex, preserving in this way the boost::shared_mutex interface.
You are right, Fredrik Orderuds solution is better because it does not break existing interface. It is incapable of making multiple lock queues of different priorities: shared_lock_prioritized<10> lock; // thread #1 // Lock with minimal priority lock.lock(); // thread #2 lock.lock(5); // thread #3 // Will acquire lock before #2, // if #2 did not already acquire lock lock.lock(6); However user usually do not need such functionality, so it does not worth breaking API. -- Best regards, Antony Polukhin
participants (2)
-
Antony Polukhin -
Vicente J. Botet Escriba