GDPicture.NET - Thread Safe

[mattewan]

Hello Loic,

A few months ago i made a topic in regards to GDPicture throwing random exceptions when running multiple threads.

Back then you said that it would be thread safe in 3 months. However, its been a bit longer than that.

In the meantime i have (sort of) got around the problem by basically, lauching 4 threads on a quad core system, then creating synclocks on all non threadsafe methods, such as opening images, writting images. So basically, only 1 thread can open or close an image at once.

That means that any functions that are thread safe (pretty much anything that doesn't modify an image, such as getting information about it) will parallel process fine.

Is there any point where GDPicture.NET will be thread safe, or is it not on the cards.

[Loïc]

Hi,

We made lot of work on this way but everything is not terminated.
Unfortunately, I can't promise a 100% thread safe toolkit today for any date.
We have too many functions & plugins to rebuild & we need to break the current architecture. I hope GdPicture.NET 7.0 will be 100% thread safe with a 64bit release.

With best regards,

Loïc

[mattewan]

Hello Loic,

Thanks for the info on that.

In this case i can do work arounds instead, like launching 4 seperate programs on a pc, which communicate over tcp/ip to complete a queue of work.

Matt

[mp285]

Hi,

I'm curious as to which functions aren't thread-safe.

My application (still in the middle of development) is using 3 threads;
1 to acquire images from the scanner and add them to a processing queue.
1 to process images from the queue (rotation/deskew/cropping/merging/etc...), and add to a save queue.
1 to save the processed images.

All 3 threads are using the same GdPicture object concurrently - and at the moment everything seems to be working fine.
I want to make sure I'm not going to break it as I add additional functionality! I'm just after a bit more clarification as to what is safe to use threads for, and what will cause problems.

Many thanks!

Mark

[Loïc]

Hi,

Since 6.4.10 version, GdPicture.NET Core should be 100% thread safe. Work is in progress for plugins (OCR, PDF rasterizer, TWAIN acquisition).

If you have any issue related to multi-threading in GdPicture.NET feel free to report it on this discussion.


Cheers,

Loïc

[DennyR]

Hello,

I guess there is a problem with thread safety.

I use the Version 6.7.5

I build a Function which instances a new GdPicture.GdPictureImaging class.
If I run more than one thread on this function, sometime it cause errors, because the object will be already used.

I avoid the problem, by SyncLocking the function. But this is not really my favorite approach.

So the GdPictureImaging Class isn’t thread save.

[Loïc]

Hi,

Please give us a way to reproduce your error.
If you can create a thread here adding basic application reproducing the error it should help us for investigation: https://www.gdpicture.com/support/getting-support-from-our-team/index.php
Please we need standalone application, no code snippet which will be not useful to be in the same condition as you are.

Note: Before releasing any new update we test all our functions in a multithread application and we have 0 known issue. So I suspect your issue to be away...

Kind regards,

Loïc

[payne296]

IsBlank seems to leak a bit of memory in a multithreaded environment. For what it's worth, I'm on 7.1 (I haven't updated to 7.2 yet). Has anybody else noticed this? While it does seem to leak, it detects blank pages correctly.

This leaks:

Code: Select all

if (gdPictureImaging.IsBlank(gdPictureReference))
{
   // Do something
}

This does not leak:

Code: Select all

lock (gdPictureImaging)
{
   if (gdPictureImaging.IsBlank(gdPictureReference))
   {
      // Do something
   }
}

[Loïc]

Hi dude,

I just cross-checked the isBlank function. And you are right
We forgot to fix a stupid problem with this function for multi-thread usage. This will be solved as soon as possible (probably for the next week).

Thank you very much for the bug report (it's rare now )

Kind regards,

Loïc