Re: [ES40-developers] c++ question
Status: Alpha
Brought to you by:
iamcamiel
From: Camiel V. <iam...@gm...> - 2008-03-11 09:14:28
|
Hi Brian, I've created our own implementations of Poco::Mutex, Poco::FastMutex and Poco::RWLock, called CMutex, CFastMutex and CRWMutex, they don't do anything special, except that they have a name, and that if DEBUG_LOCKS is defined, it will give you messages like "LOCKED mutex <name> from thread <thread>." This might help with your debugging. I've also created macro's to make life easier, and the scoped locks now use a pointer. I've put this into cvs, and converted all code to use it. Camiel. On Tue, Mar 11, 2008 at 2:36 AM, brian wheeler <bdw...@in...> wrote: > Nope, no index function...but I did figure it out. > > The constructors require references, and you can't put those into > arrays...so I resorted to mt<whatever>A and mt<whatever>B. Then the > "address always evalutates to true" warning was because index wasn't > declared in the scope (it was 'channel') so it assumed that index was > the name of a function. > > You can smack me now. Since I've got a few days off I'm going to tinker > with the locking and see if I can't figure out why its acting funny. > > Brian > > > > > > > On Mon, 2008-03-10 at 13:18 +0100, Camiel Vanderhoeven wrote: > > Hi Brian, > > > > It looks like you have a function named "index", could that be true? > > > > Camiel. > > > > On Fri, Mar 7, 2008 at 4:52 PM, Brian Wheeler <bdw...@in...> wrote: > > > This is driving me slowly insane... > > > > > > I've put this into my AliM1543C_ide.h: > > > > > > mutable Poco::RWLock mtRegisters[2]; > > > mutable Poco::RWLock mtBusmaster[2]; > > > #define LOCK_REGS(i,rw) Poco::RWLock::ScopedLock lock_regs(mtRegisters[i],rw); > > > #define LOCK_BM(i,rw) Poco::RWLock::ScopedLock lock_bm(mtBusmaster[i],rw); > > > > > > So I can have a read/write lock for each of the register sets on each of > > > the controllers. From the very limited documentation I could find for > > > the RWLock, it looks like it allows many readers but one writer. If > > > another writer tries to come in, it blocks until the writing lock is > > > free. This is what I want. And since its the ScopeLock'd variant, when > > > I drop out of my scope the lock is released. > > > > > > However, it won't compile...sort of :) When I try to compile it, I get > > > this message: > > > > > > g++ -I. -I.. -g -DHIDE_COUNTER -DDEBUG_BACKTRACE -DDEBUG_IDE -O3 -mtune=generic -DHAVE_SDL -DHAVE_X11 -DHAVE_PCAP -I/usr/include/SDL -c AliM1543C_ide.cpp -o AliM1543C_ide.o > > > AliM1543C_ide.cpp: In member function 'virtual u32 CAliM1543C_ide::ReadMem_Bar(int, int, u32, int)': > > > AliM1543C_ide.cpp:490: error: invalid types 'Poco::RWLock [2][char* ()(const char*, int)throw ()]' for array subscript > > > AliM1543C_ide.cpp:491: error: invalid types 'Poco::RWLock [2][char* ()(const char*, int)throw ()]' for array subscript > > > AliM1543C_ide.cpp: In member function 'virtual void CAliM1543C_ide::WriteMem_Bar(int, int, u32, int, u32)': > > > AliM1543C_ide.cpp:518: error: invalid types 'Poco::RWLock [2][char* ()(const char*, int)throw ()]' for array subscript > > > AliM1543C_ide.cpp:519: error: invalid types 'Poco::RWLock [2][char* ()(const char*, int)throw ()]' for array subscript > > > > > > However, those are the _second_ instances of the macro calls with the > > > arguments: > > > > > > 435: LOCK_REGS(index,false); // lock control/command registers > > > 436: LOCK_BM(index,false); // lock busmaster registers > > > 462: LOCK_REGS(index,true); // lock control/command registers > > > 463: LOCK_BM(index,true); // lock busmaster registers > > > 490: LOCK_REGS(index,false); // lock control/command registers > > > 491: LOCK_BM(index,false); // lock busmaster registers > > > 518: LOCK_REGS(index,true); // lock control/command registers > > > 519: LOCK_BM(index,true); // lock busmaster registers > > > 1023: LOCK_BM(index,true) > > > 2334: LOCK_BM(index,true); // lock busmaster registers > > > 2435: LOCK_REGS(index,true); // lock control/command registers > > > > > > So it was happy on 435, 436 and 462, 463. > > > > > > If I take out the array part it compiles just fine. If I try to fake it > > > out using a conditional in the #define, it gives a warning: > > > > > > mutable Poco::RWLock mtRegistersA; > > > mutable Poco::RWLock mtBusmasterA; > > > mutable Poco::RWLock mtRegistersB; > > > mutable Poco::RWLock mtBusmasterB; > > > #define LOCK_REGS(i,rw) Poco::RWLock::ScopedLock lock_regs((i?mtRegistersB:mtRegistersA),rw); > > > #define LOCK_BM(i,rw) Poco::RWLock::ScopedLock lock_bm((i?mtBusmasterA:mtBusmasterB),rw); > > > > > > g++ -I. -I.. -g -DHIDE_COUNTER -DDEBUG_BACKTRACE -DDEBUG_IDE -O3 -mtune=generic -DHAVE_SDL -DHAVE_X11 -DHAVE_PCAP -I/usr/include/SDL -c AliM1543C_ide.cpp -o AliM1543C_ide.o > > > AliM1543C_ide.cpp: In member function 'virtual u32 CAliM1543C_ide::ReadMem_Bar(int, int, u32, int)': > > > AliM1543C_ide.cpp:490: warning: the address of 'char* index(const char*, int)', will always evaluate as 'true' > > > AliM1543C_ide.cpp:491: warning: the address of 'char* index(const char*, int)', will always evaluate as 'true' > > > AliM1543C_ide.cpp: In member function 'virtual void CAliM1543C_ide::WriteMem_Bar(int, int, u32, int, u32)': > > > AliM1543C_ide.cpp:518: warning: the address of 'char* index(const char*, int)', will always evaluate as 'true' > > > AliM1543C_ide.cpp:519: warning: the address of 'char* index(const char*, int)', will always evaluate as 'true' > > > > > > Again, its only the 2nd time it sees the macros. The LOCK_* calls are > > > within different functions, so it shouldn't be a scope thing... > > > > > > Also, sometimes the cpu thread shuts down with an exception. I plugged > > > the segfault backtracer into it, and it looks like the culprit is > > > > > > 5 ./es40(_Z12segv_handleri+0x1c) [0x43ac9c] > > > 4 ./es40(_ZN9CAlphaCPU3runEv+0x69) [0x432ef9] > > > 3 /usr/local/lib/libPocoFoundation.so.5(_ZN4Poco10ThreadImpl5entryEPv > > > +0x88) [0x2aaaaabb47e8] > > > ^^^ Here ^^^ > > > 2 /lib64/libpthread.so.0 [0x3651e06407] > > > 1 /lib64/libc.so.6(clone+0x6d) [0x36512d4b0d] > > > > > > since frames 4 & 5 are the shutdown. > > > > > > > > > > > |