Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Once you call Synchronized(), you should use the returned wrapper
everywhere you would have used the original unsynchronized queue.
Use of the queue through the wrapper will be thread safe for all
"single operation" methods on the queue.
Make sure Synchronized() is really what you need for a thread safe queue.
Enumerating and indexing the queue aren't going to be thread safe
so you may need additional locks.
Making your own thread safe wrapper (or derived) queue class can
be better in some situations. It allows you to implement locks
the way you need to (like using a ReaderWriterLockSlim for producer/consumer
thread access) and provide properly locked enumerating methods.
Thanks for the response. Okay, so the Sync wrapper persistently replaces the Q itself, and it is the object I should pass around between methods, etc. That was not entirely clear to me before.
This should probably work for what I'm doing; I spawn a listener object on a new thread, which listens for events from a COM object. My main thread passes various Queues to the spawned object (actually, sets them as properties), and the spawned object, when it receives messages, puts a notation in the queue(s).
My main thread polls the queue, dequeuing any notations it finds.
So there's no enumerating or indexing, I think. Of course, I haven't written it yet...
It is currently displaying the stack upside down, the contents of the top of the stack are displayed as the last line in the text box. I am trying to make this code display the contents of the stack at the top of the text box.
private void displayStack()
for (int i = 0; i <= stackTop; i++)
nextItem = stackArray[i].ToString();
I recall seeing a Marquee type of control in an article here on CP. I imagine if you can find it, you could create a custom control to have the text be a linkable hypertext. If one doesn't already exist here, it would be a cool article idea.
I am developing a major application that (among other things) talks to SQL Server databases. I have it built with a platform target of "Any CPU".
However, it has to be able to import legacy data from mdb databases. The Jet database engine is only available on the 32-bit platform. I have created a .NET assembly built with a platform target of "x86" for the main application to call to do the importing.
The problem is that I get a BadImageFormatException (0x8007000b) when trying to load the dll when running 64-bit Vista. There seems to be a division of opinion about whether the 64-bit framework should be able to load 32-bit dlls.
Does anyone have a definitive answer, or a solution to the problem? I really don't want to have to build the whole app to target 32-bit just for the sake of the mdb importing functions.
The 32-bit assembly also needs to be able to call into some of the other 64-bit assemblies. Maybe this is a killer anyway?
Thanks in advance.
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.