#26 Multi-threading with different integration times in c#

[Gregory Seifert]

I have a c# application using multiple spectrometers with different integrationtimes. The manual states " juggle multiple spectrometers in different threads at different integration times" should work. I aquire data on a single thread per spectrometer, my code based on the CSharp demo. However as the spectrometer class shares a static mutex used for every call to the API, aquiring is sequential and spectrometers with long integrationtimes slow down the others. Removing the mutex results in memory corruption. Is there a way to obtain real parallel measuring?

[Kirk Clendinning]

I’m sorry to hear that you are struggling with SeaBreeze. Interestingly, I am working a similar issue using SeaBreeze, where the spectrometer is taking 10 to 20 second measurements, which as you know can be problematic.

The spectrometer in my project, the QE Pro, has the ability to take commands on two endpoints which is of some help. As well, since GetSpectrum() is essentially blocking, using an external trigger, if possible, allows one to start an acquisition and come back later to collect the data, resulting in parallel operation. The only resource contention then, would be during data retrieval. Of course the longer the integration times, the easier it is to run multiple spectrometers from SeaBreeze.

[Gregory Seifert]

I have a dozen of them and need about 50 measurements a second from each. I noticed that running multiple processes does work (c# demo can be started multiple times). Probably gonna change my design in such an approach?

[Kirk Clendinning]

Which spectrometers are you using?

Kirk Clendinning
Ocean Optics OEM
Senior Programmer/Electronic Engineer

+1 (321) 304-4641 int ext 2026
kirk.clendinning@oceanoptics.comkirk.clendinning@oceanoptics.com

On Dec 9, 2016, at 9:06 AM, Gregory Seifert gresei@users.sf.net<mailto:gresei@users.sf.net> wrote:

I have a dozen of them and need about 50 measurements a second from each. I noticed that running multiple processes does work (c# demo can be started multiple times). Probably gonna change my design in such an approach?

---

[tickets:#26]https://sourceforge.net/p/dwsim/tickets/26/ Multi-threading with different integration times in c#

Status: open
Milestone: 3.0
Labels: multithreading c#
Created: Fri Dec 09, 2016 06:43 AM UTC by Gregory Seifert
Last Updated: Fri Dec 09, 2016 01:40 PM UTC
Owner: nobody

I have a c# application using multiple spectrometers with different integrationtimes. The manual states " juggle multiple spectrometers in different threads at different integration times" should work. I aquire data on a single thread per spectrometer, my code based on the CSharp demo. However as the spectrometer class shares a static mutex used for every call to the API, aquiring is sequential and spectrometers with long integrationtimes slow down the others. Removing the mutex results in memory corruption. Is there a way to obtain real parallel measuring?

---

Sent from sourceforge.nethttp://sourceforge.net because you indicated interest in https://sourceforge.net/p/seabreeze/tickets/26/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[douga]

You should be able to run in multiple threads as long as you're using different data buffers for each spectrometer (sized appropriately per spectrometer)...Lock (mutext) protection should only be needed per spectrometer (not globally) if you anticipate any given spectrometer will be accessed from different threads. So you're right that the global mutex used in the CSharp demo is overly conservative and will cause ALL IOs to be serialzied.

[Gregory Seifert]

Thanks both for helping me!!

I use OO Flame sensors, currently 11 of them connected to a USB hub (but I have the behaviour with 2 also).

What do you mean by "different data buffers"? The objects are completely seperated, the only shared thing is the static object for thread synchronisiation (which I indeed would like to have not static).

class OceanOpticsSpectrometer : ISpectrometer, LoggerLib.ILogCapable
{
private static object _syncSeabreeze = new object(); // :( static

   public double[] getSpectrum()
    {
        double[] result = null;

        if (inErrorState)
            return result;

        try
        {
            lock (_syncSeabreeze) // without a global sync on seabreezelevel it doesn't work at all
            {

                double[] spec = new double[_pixelCount];
               SeaBreezeWrapper.seabreeze_get_formatted_spectrum(_usbIndex, ref error, ref spec[0], _pixelCount);
               ...
               }
            }
            ...
            }

from the moment the static is removed and thus per-object-locking, I receive an access violation "Attemp to read or write protected memory.

[Gregory Seifert]

I got further on this one:

1) I upgraded to the latest version on this server
2) I noticed that the release build of the dll doesn't have the problem?? I verified this several times to be sure.
3) I started debugging seabreeze.dll together with my application to see where the actual crash occurs. I noticed this was actually in the log() of the framework, somewhere a heap corruption assertion is given deeply inside stl::string
4) I removed OOI_DEBUG from the preprocessor settings and thus disabling the log() responsible for the crash and rebuild seabreeze.dll in debug
5) Now both the release and the debug version work perfectly well and fully multi-threaded.
6) I tested the result with two spectrometers with low integration times (1000 micros) and a single one with longer integration times (50000 micros). Results as expected: two "fast" spectros and a slow one, more or less independent of each other.

[Paul Solt]

I can confirm this bug as well. Logging in Seabreeze is not threadsafe in 3.0.11. Either it should be disabled by default for all build configurations, or the logger should be fixed to be threadsafe.

Seabreeze crashes on sbapi_spectrometer_get_formatted_spectrum() in the ~Log() descontructor randomly when changing integration times and hardware triggering. Also disconnecting the USB cable can cause it to crash with the Seabreeze logging enabled.

I have a crossplatform C .dll that is used with a crossplatform C++11x threaded application that has been tested on both Windows/Mac. Removing the OOI_DEBUG symbol and rebuilding debug/release 32/64 Seabreeze .dll/.dylib fixes this crash.

1. The 64-bit Windows 2013 project defaults to OOI_DEBUG, I had to modify the project and rebuild the 64-bit .dll on Windows.

2. On Mac/Linux/MinGW the Makefile has logging enabled by default, which caused it to crash for both Debug/Release builds. You need to remove the logger from the flags by commenting it out in the common.mk file and then rebuilding using make.

   # enable Logger (Logging is not thread safe in 3.0.11)
   # CFLAGS_BASE += -DOOI_DEBUG