The Nikon SDK allows for a request/response system from PC to camera through USB through the C programming language. When creating two camera objects in two seperate threads, it is not possible to send two commands simultaneously to two seperate cameras. One camera will get its command, and send back the response, and then the second camera will get its command and send back a response. I think it has to do with the fact the DLL the Nikon SDK accesses uses global variables. The DLL is not open-source, so I cannot change or verify this. I did make two seperate copies of the DLL and each thread acesses a seperate copy. Is it possible to send two commands and get responses back at the same time?
Even though you made two copies of the DLL, they are both being loaded into the same address space / process, so any conflicts will still overlap.
The first thing I would try is two separate EXEs, each loading the original DLL, so that they are running in different processes. If this allows the two cameras to be controlled independently and simultaneously, you will just need to build some kind of process isolation system :-)
The only way I know to do this (and it's not easy) is to build a COM wrapper around the Nikon DLLs and use IIS to isolate the two instances into their own processes. A slightly easier approach might be to build your own "server" for each camera, running in an EXE process, and send messages to it (maybe just Windows messages) from a third master process.
A brute force solution would be to run each process in its own virtual machine using VMWare Workstation or a similar virtual PC architecture. Of course, now you've got the problem of communicating between two virtual PCs...
Those md3 files are not thread safe and contain static functions. I got this working on the Nikon SDK by dynamically creating a new copy of the md3 file each time a camera is connected. I had one main md3 for detecting the cameras and then would create a new md3 each time I connected.
Finally, make sure your class is thread safe and contains no global or static functions. I recommend encasing the base Nikon code into a class. If your writing a 3rd party dll that requires static functions use a pointer to the Nikon class, for each static call pass the void* object that is created by your constructor.
First think I would try is spawning 2 instances of your application. One for each camera.
Not sure exactly what you're trying to accomplish. Does the answer take too long, so that you want to get the answers at the same time? Why not simply just create a wrapper and make sure the question/answer are simply synchronous, so that you can access the SDK from any thread (and in case thread X is waiting for a response and thread Y makes a request, thread Y will wait until thread X is getting the response, and then make a request).
Related
I have created a DLL in C++ VS2010.
It seems to me that 2 programs can not access it at the same time.
First program 1 has to complete the calls to the DLL, only then the DLL will process the calls from the other program.
I would like to know if there is a certain switch in the project settings that I need to set to make the DLL "multi-threaded".
The DLL is used by Windows SAPI. A program (in my case two programs) can reference the SAPI and make a computer voice (the computer voice is the DLL) speak something. I expected both programs to speak at the same time, but since they don't (they wait for each other), I expected my DLL to be single-threaded.
Thank you.
The speech API serializes speech from multiple sources so they don't play at the same time. One will play first, then the next, and so on until there is no more pending speech to be played. You can disable this via the registry as described here:
http://msdn.microsoft.com/en-us/library/ee431801(v=vs.85).aspx#_Toc494873956
Particularly the NoSerializeAccess value in HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Speech\AudioOutput\<AudioOutput1>\Attributes where <AudioOutput1> is the name of your audio output device.
This information can be found at http://msdn.microsoft.com/en-us/library/speechplatform_ispaudio.aspx
In order to prevent multiple TTS voices or engines from speaking simultaneously, the Speech Platform serializes output to objects which implement the ISpAudio interface. To disable serialization of outputs to an ISpAudio object, place an attribute called "NoSerializeAccess" in the Attributes folder of its object token.
Hi I'm working on a c++ project that I'm trying to keep OS independent and I have two processes which need to communicate. I was thinking about setting up a 3rd process (possibly as a service?) to coordinate the other two, asynchronously.
Client 1 will tell the intermediate process when data is ready, and send the data to it. The intermediate process will then hold this data until client 2 tells it that it is ready for the data. If the intermediate process has not received new data from client 1, it will tell client 2 to wait.
Since I am trying to keep this OS independent I don't really know what to use. I have looked into using MPI but it doesn't really seem to fit this purpose. I have also looked into Boost.ASIO, Named Pipes, RPC's and RCF. Im currently programming in Windows but I'd like to avoid using the WIN_API so that the code could potentially be compiled in Linux.
Here's a little more detail on the two processes.
We have a back end process/model (client 1) that will receive initial inputs from a GUI (client 2, written in Qt) via the intermediate process. The model will then proceed to work until the end condition is met, sending data to the server as it becomes ready. The GUI will ask the intermediate process for data on regular intervals and will be told to wait if the model has not updated the data. As the data becomes available from the model we also want to be able to keep any previous data from the current session for exporting to a file if the user chooses to do so (i.e., we'll want the GUI to issue a command to the interface to export (or load) the data).
My modification privleges of the the back end/model are minimal, other than to adhere to the design outlined above. I have a decent amount of c++ experience but not much parallel/asynchronous application experience. Any help or direction is greatly appreciated.
Standard BSD TCP/IP socket are mostly platform independent. They work with some minor differences on both windows and Unices (like linux).
PS windows does not support AF_UNIX sockets.
I'd checkout the boost.interprocess library. If the two processes are on the same machine it has a number of different ways to communicate between processes, and do so in an platform independent manner.
I am not sure if you have considered the messaging system but if you are sending structured data between processes you should consider looking at google protocol buffers.
These related to the content of the messaging (what is passed) rather than how they are passed.
boost::asio is platform independent although it doesn't imply C++ at both ends. Of course, when you are using C++ you can use boost::asio as your form of transport.
I am trying to make an AIR application, that needs to pass an image (.jpg/.png) to a C++ app, that does number crunching.(this needs to be done very often, like every 2-3 seconds.) I've managed to pass the image by saving it to disk via AIR, then opening this file with the C++ program (and passing the filename as an argument to the C++ program), but this method is really slow, because it involves lots of disk I/O.
Is there a method to send an image directly to a native process?
Edit: There is a good Flash-C++ communication example at http://www.marijnspeelman.nl/blog/2008/03/06/face-detection-using-flash-and-c-revisited/ using sockets. The big problem with this method is, that some firewall settings can block the communication (i get a windows firewall warning, when i start the app).
There are several ways to transmit data between two processes.
One of the most efficient, and easy to setup, is to use TCP sockets.
It means that your C/C++ will for (TCP/HTTP) requests, and that your AIR program will send the request with all data inside.
I'm trying to capture the audio which an activeX flash component is playing.
I do this by finding the flash.ocx module and hook the waveOutWrite function.
This seems to work well, however I cannot differentiate between different activex instances which call waveOutWrite internally as the audio seems to come from the same thread and target the same output device.
My question is how I could differentiate between who is calling waveOutWrite?
I think the answer lies in somewhere in loading a flash.ocx instance for each activex instance, not sure how to achieve that though as the module loading is handled automatically by COM. One idea I had was to create the activex components in different processes, which hopefully would cause the waveOutWrite function to be called from different threads. However, this seems to be a rather complicated way to achieve this.
Any ideas?
I am really surprised that several OCX instances share the same thread. I could have sworn that they get unique ones. Hence my previous [deleted] answer.
May I ask: why are you playing several sounds at once? Is that absolutely necessary? Or, if the other OCX instances are playing "mute" sound, you could identify them by looking into the waveform buffer. Or possibly, other data in the WAVEHDR struct, perhaps dwUser...
I'm work on a build tool that launches thousands of processes (compiles, links etc). It also distributes executables to remote machines so that the build can be run accross 100s of slave machines. I'm implementing DLL injection to monitor the child processes of my build process so that I can see that they opened/closed the resources I expected them to. That way I can tell if my users aren't specifying dependency information correctly.
My question is:
I've got the DLL injection working but I'm not all that familiar with windows programming. What would be the best/fastest way to callback to the parent build process with all the millions of file io reports that the children will be generating? I've thought about having them write to a non-blocking socket, but have been wondering if maybe pipes/shared memory or maybe COM would be better?
First, since you're apparently dealing with communication between machines, not just within one machine, I'd rule out shared memory immediately.
I'd think hard about trying to minimize the amount of data instead of worrying a lot about how fast you can send it. Instead of sending millions of file I/O reports, I'd batch together a few kilobytes of that data (or something on that order) and send a hash of that packet. With a careful choice of packet size, you should be able to reduce your data transmission to the point that you can simply use whatever method you find most convenient, rather than trying to pick the one that's the fastest.
If you stay in the windows world (None of your machines is linux or whatever) named pipes is a good choice, because it is fast and can be accessed across the machine boundary. I think shared memory is out of the race, because it can't cross the machine boundary. Distributed com allows to formulate the contract in IDL, but i think XML Messages via pipes are also ok. The xml messages have the benefit to work completely independent from the channel. If yo need linux later you can switch to tcp/ip transport and send your xml messages.
Some additional techniques with limitations:
Another forgotten but hot candidate is RPC (remote procedure calls). Lot of windows services rely on this. But i think it is hard to program RPC
If you are on the same machine and you only need to send some status information, you can regisier a windows message via RegisterWindowMessage() and send messages vie SendMessage()
apart from all the suggestions from thomas, you might also just use a common database to store the results. And if that is too slow use one of the more modern(and fast) key/value databases (like tokyo cabinet/memcachedb/etc).
This sounds like a lot of overkill for the task of verifying the files used in a build. How about, just scanning the build files? or capturing the output from the build tools?