Commit Graph

2 Commits

Author SHA1 Message Date
digit@google.com
1771cbf43d posix: Avoid static initializers in static/global mutexes
This patch removes static initializers related to static and
global mutexes from the final library's machine code when
building on a pthread-capable system.

We use PTHREAD_MUTEX_INITIALIZER to perform POD-style
initialization. You need a line like the following to declare
a global mutex with it:

    SkBaseMutex gMutex = { PTHREAD_MUTEX_INITIALIZER };

We introduce the SK_DECLARE_STATIC_MUTEX and SK_DECLARE_GLOBAL_MUTEX
macros to be able to declare static/global mutexes in the source tree
uniformly.

SkMutex is now defined as a sub-class of SkBaseMutex, with standard
construction/destruction semantics. This is useful if the mutex
object is a member of another C++ class, or allocated dynamically.

We also modify a few places to refer to SkBaseMutex instead of a
SkMutex, where it makes sense. Generally speaking, client code
should hold and use pointers to SkBaseMutex whenever they can
now.

We defined a new built-time macro named SK_USE_POSIX_THREADS
to indicate that we're using a pthread-based SkThread.h
interface. The macro will also be used in future patches
to implement other helper thread synchronization classes.

Finally, we inline the acquire() and release() functions in the
case of Posix to improve performance a bit.

Running: 'bench -repeat 10 -match mutex' on an Android device or
a 2.4GHz Xeon Linux desktop shows the following improvements:

                      Before     After

        Galaxy Nexus    1.64      1.45
        Nexus S         1.47      1.16
        Xoom            1.86      1.66
        Xeon            0.36      0.31

This removes 5 static mutex initializers from the library
Review URL: https://codereview.appspot.com/5501066

git-svn-id: http://skia.googlecode.com/svn/trunk@3091 2bbb7eff-a529-9590-31e7-b0007b416f81
2012-01-26 21:26:40 +00:00
tomhudson@google.com
410e9dc9aa New SkMutex benchmark - used when we suspected mutex performance issues;
committed not because they're a bottleneck now but because we might do
something with them in the future & it's quite lightweight.



git-svn-id: http://skia.googlecode.com/svn/trunk@2675 2bbb7eff-a529-9590-31e7-b0007b416f81
2011-11-14 17:30:08 +00:00