Re: [Lcms-user] Multi-Threading Best Practices

[Bob F. <bfr...@si...>]

On Fri, 17 Dec 2010, Marti.Maria wrote:
> 
> 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.

In my experience, both Windows and POSIX provide thread specific data 
("TSD") APIs which are much more efficient than using mutexes for 
doing things like accessing redundant caches without API 
modifications.  The way this works is that your pointer is stored in a 
thread-specific area so that it is found efficiently with one array 
indexing operation.  TSD could be used to support the single-pixel 
cache you mention.

In GraphicsMagick I use this approach in the random number generator 
to store per-thread random number kernels.  Random number generation 
performance went up by many times as compared to sharing one kernel 
via a mutex.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/