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 list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
------------------------------------------------------------------------
Se certificó que el correo no contiene virus.
Comprobada por AVG - www.avg.es <http://www.avg.es>
Versión: 10.0.1170 / Base de datos de virus: 426/3320 - Fecha de la
versión: 16/12/2010
------------------------------------------------------------------------------
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
