déjà j'évite le trylock donc j'avoue que le probleme c'est jamais posé pour moi
le code multithread est deja suffisemment complexe pour ne pas rajouter des cas particuliers par dessus
si c'est utile, un truc comme:
Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
| class ScopedMutexTryLock
{
private:
Mutex& m_mutex;
bool m_result;
public:
inline ScopedMutexTryLock(Mutex& m) : m_mutex(m), m_result(m.trylock()) { }
inline ~ScopedMutexTryLock() { if(m_result) m_mutex.release(); }
operator bool() const { return m_result; }
bool operator !() const { return !m_result; }
};
int foo()
{
ScopedMutexTryLock lock(m_mutex);
if(lock)
{
}
} |
c'est forcément gênant puisque le if est "optionnel" et il est possible de le confondre très facilement avec le ScopedMutexLock. Mais comme dit plus haut, je ne l'ai pas ajouté donc le problème se pose pas pour moi.
Après pour la contre-productivité, ca se discute. Moi je dis que le couple lock/release a un coût caché qui est le temps de debugging que l'objet lock n'a pas. et j'aime bien que l'on prenne en compte le temps perdu a réparer un truc. Mais je comprends ce que tu veux dire, c'est un peu moins flexible et il se peut qu'il faille se contortionner un peu pour l'utiliser.