Threading in plugin code

[_Aaron_Sher_]

I'm trying to write a plugin that does some very time-consuming image processing, and I'm trying to use multiple threads to improve performance. I first tried using OpenMP, which worked fine, except that if we executed any OpenMP pragma (even a critical or atomic), Photoshop would crash later (after the plugin is closed).

So, I concluded that Photoshop and OpenMP don't get along, and I switched to using Intel's Threading Building Blocks library. With that, I get similar behavior - executing any parallel algorithm, even if I've only got one thread, and even if I don't *do* anything inside the parallel block, causes Photoshop to crash on exit.

Has anybody done something like this successfully? Was there a trick to it? I could write threads by hand, but I don't have any reason to believe that it's going to work any better.

For what it's worth, all of this threading is happening inside a static library built using the Intel C++ compiler v10.1, linked into a plugin built using GCC 4.0. Needless to say, all of this code works perfectly in my test applications.

Thanks,
Aaron

[_Ondrej_Psencik_]

And why you are not using destination OS threading functions? E.g. pthread for mac and Winbase.h in Win.

Do you join threads before you quit plugin?

I noticed also mystical crashes of Photoshop (not related to threading) but when used particular Carbon string functions on Mac. This is fracking magic and you have to play with it.

PS:
It has to work but you can not spawn threads and then return main thread from plugin to Photoshop I think if you do so.

And I would consider all suites calls as critical sections, avoiding using suites from multiple threads simultaneously.

PS2:
And I would debug Photoshop, I had to do this several times. Just run it attach debugger if it crashes you will probably see where the problem is, maybe it's in threading library somewhere.

[_Ivan_Kharin_]

Don't call Photoshop functions via FilterRecord from other threads!
Photoshop API isn't thread-safe.

[_Aaron_Sher_]

First, I'm using OpenMP and/or TBB because it's a hell of a lot easier, more efficient, and more cross-platform than using native threads. I could do it with native threads, and it's possible that it would work, but I'm saving that for a last resort.

Second, I'm not doing anything at all in my threads at the moment - in the case of OpenMP, if the code encounters *any* OpenMP pragmas at all, even just a critical or atomic, Photoshop will crash later. If there are no pragmas, there's no crash. I don't have to even create threads for this to happen.

I can attach a debugger to Photoshop, but when it crashes it's nowhere near my code. The actual crash (in the OpenMP case) occurs in Photoshop's Open dialog, and only when it's in thumbnail view. No idea why.

I have to partially retract my statement about TBB. The crash that I'm seeing seems not to be directly related to TBB calls, but I haven't yet figured out what it is. It's possible that in the course of switching over to TBB I managed to break something else - I'm investigating this now. This may yet be a workable solution.

Thanks,
Aaron

[_Aaron_Sher_]

No, I was right the first time. Making a single call to tbb::parallel_for will cause Photoshop to crash on exit. This happens even if I've initialized TBB with a single thread (so there's no actual parallelism going on), and even if the body of my algorithm doesn't do anything.

Aaron

[qu1j0t3]

This is known as "a world of hurt"... just based on your description (I've never tried it, but would expect pretty much the amount of pain you found).

Adobe really needs to document this stuff better.

[_Ondrej_Psencik_]

I quickly took a look at intel web site and there is sentence
(http://softwarecommunity.intel.com/articles/eng/1197.htm)

"At the end of the parallel region, threads are suspended"

Therefore I asked question if you join threads if you leave plugin.

You have to ensure that you quit all threads when leaving plugin, but it's quesiton how to achieve this with OpenMP.

So start plugin in debugger and watch threads, if the threads remain after processing quit from plugin then this is problem.

[_Aaron_Sher_]

I got it working using Threading Building Blocks. My original problem with TBB seems to have been resolved by explicitly releasing all PS suites when the plugin closes (including those acquired by PS code). I did this by making a wrapper around the basic suite that tracks suite acquisitions, and then releasing them all by hand when my filter closes.

Never got OpenMP to work. There wasn't an issue with joining threads, because I'm threading only a small part of my process - by the time I close the filter, it's long since over.

Thanks,
Aaron

[Royi A]

I have a similar problem.

Yet it happens only on OS X.

I run one of my Plug In's which uses OpenMP.
Then I run another one and Photoshop crashes.

Looking on the Crash Report it seems the previous one left some threads though it finished its task.

How can I make those "Threads" close?

I really need this OpenMP for our tasks.

Why does it happen only on OS X?

I use OS X 10.10 with Intel Compiler 2015 Update 6.

[Guest]

The gain by using OpenMP IMO is not worth the stretch...

Use OpenCL. That's where the scores will really change.

It aint easy to integrate, especially if you use the adobesdk documentation which is more misguiding that guiding.

One word of advice... Ditch the Documentation and try and map the code from Dissolve in to your own logic.

It will take you weeks but you will learn a lot and learn how you can ditch a whole lot of the superfluous code resting inside the dissolve plug...

To Adobe, you really should put up a disclaimer warning folks about the documentation. It would have saved us weeks. We actually took the documentation seriously and got bitten very BADLY  - time wise - because of it. It is extremely outdated and completely missing the important links that would qualify it as being - well - documentation...

Also, the Dissolve Plug-in Template has a LOT of bugs and empty Code which for a template allowing third party developers to write photoshop plugs - isnt really necessary.

[Royi A]

Hi,

I agree with you OpenCL might introduce better results.
But now the code is optimized to work with OpenMP and I wonder what is the right way to use it.

It seems to work perfectly in Windows yet in OS X there are many issues.