From: John C. <jc...@gm...> - 2006-05-12 15:04:20
|
Hello all, I've just noticed cmsDoTransform() isn't threadsafe (when I found random image corruption on my SMP box, heh). Has any thought gone into making a threadsafe version? If I looked at this, would there be interest in patches? John |
From: Boudewijn R. <bo...@va...> - 2006-05-12 19:06:53
|
On Friday 12 May 2006 17:04, John Cupitt wrote: > Hello all, > > I've just noticed cmsDoTransform() isn't threadsafe (when I found > random image corruption on my SMP box, heh). > > Has any thought gone into making a threadsafe version? If I looked at > this, would there be interest in patches? Eeek... I was wondering about this after I got some crashes in an experimen= tal=20 version of Krita, too, but I rather hoped it wasn't this problem. I would=20 very much like a threadsafe lcms, especially because Krita 2.0 is being=20 designed to make good use of every chance at parallellism. =2D-=20 Boudewijn Rempt=20 http://www.valdyas.org/fading/index.cgi |
From: Marti <ma...@li...> - 2006-05-13 13:18:17
|
Hi, >Eeek... I was wondering about this after I got some crashes in an >experimental > version of Krita, too, but I rather hoped it wasn't this problem. It works fine as long as you use just one color transform per thread. Sharing transforms between threads doesn't work because the 1-pixel cache. So you must, either, use just one tranform per thread or inhibit the caching by using cmsFLAGS_NOTCACHE. I recommnd to leave the cache alone and limit to one thread by transform. Cache *does* make a difference. Incoming 1.16 will have more support for multithreading, though. Regards Marti Maria The littleCMS project http://www.littlecms.com ----- Original Message ----- From: "Boudewijn Rempt" <bo...@va...> To: <lcm...@li...> Sent: Friday, May 12, 2006 9:06 PM Subject: Re: [Lcms-user] threading On Friday 12 May 2006 17:04, John Cupitt wrote: > Hello all, > > I've just noticed cmsDoTransform() isn't threadsafe (when I found > random image corruption on my SMP box, heh). > > Has any thought gone into making a threadsafe version? If I looked at > this, would there be interest in patches? Eeek... I was wondering about this after I got some crashes in an experimental version of Krita, too, but I rather hoped it wasn't this problem. I would very much like a threadsafe lcms, especially because Krita 2.0 is being designed to make good use of every chance at parallellism. |
From: Boudewijn R. <bo...@va...> - 2006-05-13 13:27:52
|
On Saturday 13 May 2006 15:18, Marti wrote: > Hi, > > >Eeek... I was wondering about this after I got some crashes in an > >experimental > > version of Krita, too, but I rather hoped it wasn't this problem. > > It works fine as long as you use just one color transform per thread. > Sharing transforms between threads doesn't work because the > 1-pixel cache. So you must, either, use just one tranform per thread or > inhibit the caching by using cmsFLAGS_NOTCACHE. > I recommnd to leave the cache alone and limit to one thread > by transform. Cache *does* make a difference. Okay, I'll mutex for now. Krita 2.0 won't be released until April 2007 anyw= ay. > Incoming 1.16 will have more support for multithreading, though. Great -- I expect that 1.16 will be released before Krita 2.0 :-) =2D-=20 Boudewijn Rempt=20 http://www.valdyas.org/fading/index.cgi |
From: John C. <jc...@gm...> - 2006-05-15 10:43:15
|
On 5/13/06, Marti <ma...@li...> wrote: > It works fine as long as you use just one color transform per thread. > Sharing transforms between threads doesn't work because the > 1-pixel cache. So you must, either, use just one tranform per thread or > inhibit the caching by using cmsFLAGS_NOTCACHE. > I recommnd to leave the cache alone and limit to one thread > by transform. Cache *does* make a difference. OK, I'll just mutex on cmsDoTransform() for now. Thanks! John |
From: Louis S. [SteelBytes] <lo...@st...> - 2006-05-16 12:18:51
|
> Incoming 1.16 will have more support for multithreading, though. and what's the ETA on 1.16? 1week? 1month? 6months? Louis Solomon www.SteelBytes.com |
From: Marti <ma...@li...> - 2006-05-17 08:21:33
|
Hi, >> Incoming 1.16 will have more support for multithreading, though. > > and what's the ETA on 1.16? 1week? 1month? 6months? Release date of 1.16 is not clear since each release requires an IP review. August seems reasonable. Some additions are already in CVS. Regards Marti ----- Original Message ----- From: "Louis Solomon [SteelBytes]" <lo...@st...> To: "lcms-user" <lcm...@li...> Sent: Tuesday, May 16, 2006 2:18 PM Subject: Re: [Lcms-user] threading >> Incoming 1.16 will have more support for multithreading, though. > > and what's the ETA on 1.16? 1week? 1month? 6months? > > Louis Solomon > www.SteelBytes.com > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > > |
From: Bob F. <bfr...@si...> - 2006-05-13 03:58:52
|
On Fri, 12 May 2006, John Cupitt wrote: > > I've just noticed cmsDoTransform() isn't threadsafe (when I found > random image corruption on my SMP box, heh). What part of the code is not thread safe? Are you sure that the thread safety problem is not a problem with your own application or the way the lcms library was built? > Has any thought gone into making a threadsafe version? If I looked at > this, would there be interest in patches? No doubt there would be interest in patches if you were to isolate and solve a problem in lcms. Bob ====================================== Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: John C. <jc...@gm...> - 2006-05-13 12:57:48
|
On 5/13/06, Bob Friesenhahn <bfr...@si...> wrote: > On Fri, 12 May 2006, John Cupitt wrote: > > I've just noticed cmsDoTransform() isn't threadsafe (when I found > > random image corruption on my SMP box, heh). > > What part of the code is not thread safe? Are you sure that the > thread safety problem is not a problem with your own application or > the way the lcms library was built? I'm calling cmsDoTransform() from more than one thread with the same cmsHTRANSFORM pointer. I see random corruption, like noise, in the output image. So I guess cmsDoTransform() must be using part of the transform as working area. I either have to mutex around each call to cmsDoTransform() (so I lose parallelism), or I have to have a separate transform for each thread. The problem with a separate transform for each thread is that transforms are rather 'heavy' objects. They can take a lot of time to build, and use a lot of memory (is this correct? I've not done any tests, but the docs seem to imply this). It seems very wasteful to have to build many identical transforms. It seems to me that cmsDoTransform() should not modify the transform object. Transforms ought to be split into a read-only section (shared by all threads using that transform), and per-thread storage. You might be able to change this in a backwards compatible way. Perhaps cmsDoTransform() could become: cmsDoTransform( transform, in, out, n ) { data =3D cmsTransformDataNew() cmsDoTransformData( transform, data, in, out, n ) cmsTransformDataFree( data ) } ie. alloc and free some per-thread storage on each call. But I've no idea how large the per-thread area needs to be. If this is too slow, the lcms API would probably have to change. John |