Re: CSingleLock same-thread double-access problem.
On Mon, 24 Sep 2007 11:56:24 +0200, "Ricardo Vazquez" <rvazquez@dummy.com>
wrote:
I'm afraid that something went wrong with my post! It lost most of its
carry-returns!
So I post it again, and I hope this time it's readable!
Cheers,
Ricardo
---------------------------
This is my scenario:
My application has one instance of:
class CMapDevices : public CMap <long, long&, CDevice*, CDevice*&>
Several threads can access this CMap; but they must not access it at the
same time.
So I added these member variables to CMapDevices:
CSemaphore* m_sem;
Why is this a pointer? Just make it a CSemaphore.
CSingleLock* m_lock;
The CSingleLock class should only ever be used to define local variables.
(...)
CMapDevices ::CMapDevices ()
{
CString sSemaphoreName;
sSemaphoreName.Format("devs-%f",(double)(DATE)COleDateTime::GetCurrentTime());
m_sem = new CSemaphore (1, 1, sSemaphoreName);
m_lock = new CSingleLock(m_sem);
}
So that wherever my code accesses the map I call
m_lock->Lock(3000)
before the access, and then
m_lock->Unlock()
after the access.
You must not share CSingleObject objects between threads. Also, what do you
do if Lock returns due to a timeout?
My problem is this:
Under certain circumstances, within the same thread, this is the code flow
Iget:
[within the same thread]
-Access to map (lock)
|
|--2nd. access to map (lock -again- for the same thread)
|
|--2nd. access finishes (unlock)
|
-1st. access finishes (the map was already unlocked... but it shouldn't!)
As you can see, when the 2nd. access finishes the map is unlocked for
thisthread, so that any other thread could access it: but the map should be
keptlocked until the first access finishes!
So my question is:
What synchronization objects and access-control mechanisms should I use to
manage this possible situation and how should I use them?
Any other hints or clues?
Any helpful code I could find over the Internet?
Here is an example of using CSingleLock:
void f()
{
CSingleLock lk(&m_sema, true);
// Now access the data m_sema guards.
}
BTW, I don't know why you're using a semaphore instead of a mutex. It
sounds like you should be using a CMutex if you need the timeout capability
or CCriticalSection if you don't. I agree with Giovanni's class design
suggestions, but beware composite operations for which the entire sequence
of operations must be locked. If this comes up, the user of the class is
going to have to do his own locking for *everything*, such that
CMapDevices's locking becomes redundant.
--
Doug Harrison
Visual C++ MVP