> I'm trying to use a CCriticalSection, but failing. I get access
> violations when I try to lock. So I'm clearly doing it wrong.
Can you verify that the critical section is successfully created inside the
ctor?
> Here's the scenario:
>
> Class A creates a worker thread.
> Class A wants to queue up items for the worker thread to handle one at
> a time. These items can be represented by a single UINT.
>
> Thus, I believe I am correct in saying that I should be using a
> critical section to control putting things into the queue and pulling
> things out of the queue, so they don't clash.
> (Clearly I've never used a sync object before).
Yes, you're right.
> For now, I was trying to use a CUIntArray as the queue itself
> (probably not the most efficient, but I just want to get it working
> first before I worry about efficiency - but I'm open to better
> suggestions of MFC (not ATL,
> sorry) objects to use for a queue).
Well, switch to std::queue which truly represents a FIFO queue. Use
std::stack is LIFO is the behavior you need.
> But, this array is a member of a structure declared globally:
>
> (Header file)
> typedef struct tagItemQueue
> {
> BOOL bTerminate ;
> CUIntArray aryItems ;
>
> } ITEM_QUEUE ;
>
> (Implementation file)
> static const g_sItemQueue ;
>
> This is passed (by its pointer) as the user parameter to the worker
> thread on creation (I could use the global reference, but chose not
> to). The worker thread then tries to access it.
>
> This all seems to work fine.
This is not the design that I would follow. Your below code is far better.
> So now I tried adding a critical section, by updating the structure:
>
> typedef struct tagXXX
> {
> BOOL bTerminate ;
> CUIntArray aryItems ;
> CCriticalSection CriticalSection ;
>
> } XXX ;
This struct is created once, and passed to the worker thread, right? To
make sure it acts as we expect it to, try providing a private copy ctor and
assignment operator without any implementation (only the function
declarations) to see if the code goes on to compile fine or not.
> Accordingly, in the thread (and where it tries to add things to the
> queue), I try:
>
> if (psQueue->CriticalSection.Lock(1000) ) {
> // Do something thread-safely...
>
> psQueue->Unlock();
> }
>
>
> But when I run the program, it access violates at the .Lock() line.
That shouldn't happen. Can you step through the Lock( ) call and see if the
m_crit member of the CCriticalSection object is correctly set?
> Have I done something wrong? This is the best I can make out from MSDN
> on CCriticalSection (I tried using a CSingleLock in conjunction with
> it, but that failed too, although for different reasons that I can't
> fathom - so I used the critical section directly, as MSDN says I can).
Yes, you can use them alone, and I can't see any problem with the layout you
explain. Unless of course you're doing something unwantedly which breaks
things up.
-------------
Ehsan Akhgari
Farda Technology (http://www.farda-tech.com/)
List Owner: [EMAIL PROTECTED]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
Man is something that must be overcome: and therefore you will love your
virtues,- for you will perish by them.-
-Thus Spoke Zarathustra, F. W. Nietzsche
