Hi Adam,
cmsDoTransform() never signals an error. If you take a look on the prototype, it has no return code and it does not call the error handler. The transform construction may fail, but once you get a valid transform you are granted to be able to apply it without any error. You already have discovered the reasons for such behavior. Do the error handling only once in the main thread and then split the image processing in multiple sub threads. There is no need of error handling in those. I think this is a pretty simple and practical solution. Regards Marti Original Message: ----------------- From: Adam Augusta rox...@gmail.com Date: Fri, 17 Dec 2010 11:26:33 -0500 To: marti.ma...@littlecms.com, Lcms-user@lists.sourceforge.net Subject: Re: [Lcms-user] Multi-Threading Best Practices Excellent. Thank you very much for your feedback, Marti. On your advice, I'm tempted to disable the cache and skip thread pooling, but there's one problem. If cmsDoTransform signals an error, I'd like to throw an exception. I can't throw an exception in the callback method, so I'd have to match up the error after lcms returns. In order to match up the error with the right lcms call, I'd need a thread-specific ContextID in the error, which I could only achieve by having one thread per transform. Maybe I should give up on throwing a meaningful exception, and simply log the error instead. I suspect, though, that I'm overlooking a more straightforward solution. -Adam On Fri, Dec 17, 2010 at 10:37 AM, Marti.Maria <marti.ma...@littlecms.com>wrote: > > Hi Adam, > > Actually is a lot more simple. ContexID is nothing else that a void pointer > that user can associate to profiles and/or transforms. It has no meaning. Is > just a sort of used defined cargo that you can use on your convenience. lcms > does nothing with that . It has no relationship with threads, but can be > used to store information about the thread. Obviously you can ignore it if > wish so. Then, by default this void pointer is set to NULL when creating the > transform or opening the profiles. Additionally, if the programmer wish, > there are functions which end with THR that can set the this to values other > than NULL. In this way the threads, processes or wathever that are using the > profiles and transforms can retrieve the value. It is just a way to store a > 32 bit value along the handles. > > On the other hand we have the 1-pixel cache. This is very convenient on > slow interpolation methods when most of the pixels in the image are similar. > Obviously, caching means the transform should store the result of last > processed pixel, then in the case two threads are using the same transform > at the same time, memory read/write operations on this value may clash and > therefore you need some sort of semaphore. Ok, you can use a semaphore (the > pthreads) or just get rid of the cache enterely. Please note that in some > situations the cache is not used at all, i.e., on matrix-shaper to > matrix-shaper 8 bit, it is actually faster to do always the computations, so > the cache schema is discarded on this case. On CMYK trilinear, cache is > being used as interpolation tends to be slow. > > So, to answer your questions: If you use redundant transforms, you need not > to worry about anything as each transform is using different cache. May be > fast, but this is big a waste of memory. If you share the same transform on > several threads, which is very efficient, you have either to disable the > cache or to enable pthreads. I would reccomend to disable the cache, the > performance gain when using multiple threads is huge, the performance gain > when using cache is small. If you need more performance, just add more > threads. You have not to use cmsCreateTransformTHR, this is just a way to > add a user-defined variable to the handle, and finally cmsDoTransform does > not have any ContexID, the error reports the ContextID associated with the > transform being used. As a hint, ContexID are more useful when you want > write a memory management plug-in to specialize memory mangement for > multithreading, as the memory management pluging does recive ContextID when > a memory operation is requested. The testebed application does use this > feature to check memory consistency. > > Hope that helps > Marti > > > > Adam Augusta wrote: > > There have been a few posts about multi-threading on this list, but I'm > still a little fuzzy on best practices. So let me rattle off a few > questions and factoids, then propose best practices to see if they sound > reasonable. > > * My understanding is that if I don't want to enable pthreads or disable > the cache, I'll want redundant transforms for each worker thread. > * Bob Friesenhahn mentioned that having each worker thread create the > transforms it uses should improve performance on some platforms. > * To get thread-safety in creating transforms, I'll need to use > cmsCreateTransformTHR. > * Curiously, LCMS2 permanently associates a ContextID with a created > profile. Should I infer from this that I should also create redundant > profiles for each thread? > * cmsDoTransform doesn't take in a ContextID. If there's an error during > the transform, what gets reported to the callback? The ContextID associated > with the transform? > > In summary... > Best Practices: > 1) Each worker thread creates its own profiles (?) using THR methods. > 2) Each worker thread creates its own transforms using THR methods. > 3) If I use a ContextID in the above methods that denotes the worker > thread, I should be able to identify the appropriate worker thread in the > error callback under just about any use case. (?) > > Ideally, I'd prefer to avoid having a worker thread pool in my > application, but it seems like the best way to use LCMS today. > > Thanks, > -Adam > > ------------------------------ > > ---------------------------------------------------------------------------- -- > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business.http://p.sf.net/sfu/lotusphere-d2d > > ------------------------------ > > _______________________________________________ > Lcms-user mailing listlcms-u...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listi nfo/lcms-user > > > ------------------------------ > > Se certificó que el correo no contiene virus. > Comprobada por AVG - www.avg.es > Versión: 10.0.1170 / Base de datos de virus: 426/3320 - Fecha de la > versión: 16/12/2010 > > > -------------------------------------------------------------------- mail2web LIVE Free email based on Microsoft® Exchange technology - http://link.mail2web.com/LIVE ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
