[Pixman] [PATCH 2/2] test: Add new thread-test program

[Andrea Canciani]

On Sun, Sep 29, 2013 at 10:02 PM, Søren Sandmann <sandmann at cs.au.dk> wrote:

> Andrea Canciani <ranma42 at gmail.com> writes:
>
> > I have some work on memleak related issues:
> >
> >
> http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/simpleops-to-master&id=77db90242f7b7f12c5792480a10eb3a448e6c55f
> > and
> >
> http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/simpleops-to-master&id=ca41228a66fe9bbec354cdef034c144ce1619793
> >
> > Do you think it might be worth to revive it and cleanup for review &
> merge?
> > Unfortunately they depend on simpleops, a header-library I wrote to
> > abstract (from compiler/platform) some low-level operations, like atomic
> > arithmetics, mutexes, threads and library constructors/destructors.
> > (currently all of them except init/fini are available in C11 and the
> > simpleops API tries to be as similar to C11 as possible, to ease
> C11-based
> > implementations and to make it easy to get rid of the simpleops
> dependency
> > when C11 support is sufficiently widespread).
> > Would it be ok to have it as dependency?
>
> At some point pixman probably needs to become multithreaded and then we
> will need some abstraction for these low-level operations.
>
> I think I have mentioned before that it might be a good idea to have an
> MIT licensed utility library that could contain these lowlevel
> operations along with things like linked lists and growable
> arrays.


Linked-list and hashtables are available in
http://cgit.freedesktop.org/~ranma42/simpledata
I could add growable arrays, if this is blocking the adoption of this
abstractions.

>
> Until simpleops grows into such a library, I think I'd prefer to
> keep the abstractions inside pixman, though those internal abstractions
> could potentially be based on code from simpleops.
>

These header-based libraries can easily (assuming the build process is
autotools or win32-makefile based) be included as git submodules.
(You might have noticed that they also provide some helpers for symbol
visibility

>
>
> There is also a general issue with header libraries: they have
> potentialy complicated ABI issues because the code is inlined into all
> users, so if any aspect of the code changes, you have to recompile
> everything.
>
> Looking briefly at the simpleops code, I noticed a few things:
>
> - There doesn't appear to be support for __thread for thread local
>   variables.
>

Exactly. I tried to implement them, but having all of them working with the
same interface proved to be a very hard task.
For example, on Windows there seem to be some problems when dynamically
loading libraries that use __declspec(thread) (this seems to be a known
limitation, see http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx and
http://support.microsoft.com/kb/118816 )
Instead, simpleops provides a C11-like thread-specific storage API.


>
> - It's a bit difficult to understand all the headers that include each
>   other. (The proliferation of headers is something that I never liked
>   about the cairo code as well). Would it be possible to just have one
>   header per platform -- ie., simpleops-win32.h, simpleops-posix, ...?
>

It should be possible, but there seem to be quite a lot of platforms,
because sometimes the features are made available by the compilers
(example: atomics on gcc and msvc) while sometimes they depend on the
system library (example: threads).
In addition to that, currently some common code is factored out and the
files are structured so that they can be compared and extended (adding a
new implementation or adding functions to all implementations) easily.
All in all I believe it would be possible to have simpleops-win32-gcc.h
simpleops-win32-msvc.h simpleops-mac-posix.h simpleops-suncc-posix.h and so
on, but I'm afraid it would be harder to maintain.
For an efficient way to view and compare the implementations, see
file:///path/to/simpleops/index.html?atomic/impl/_dispatch.h (and similarly
using "mtx", "cnd", and so on instead of "atomic")


> - There is no way to statically initialize a mutex. I realize that
>   that's because Windows doesn't offer this feature, but without it,
>   you need some kind of library initialization routine.
>

Library initialization routine are provided, so you can use them both for
mutex initialization and for TSS setup.
A possible alternative would be to use something like call_once(), but it
is pretty hard to perform the proper deinitialization upon library unload
if you use that.


>   I wrote some notes here:
>
>
> http://cgit.freedesktop.org/~sandmann/pixman/tree/docs/thread-primitives?h=docs
>
>   about how you could emulate them on Windows.
>

Instead of static mutex initialization, your docs seem to be suggesting
that call_once() should be made available.
Would that be sufficient?
How would you destroy/free that data that has been created/allocated in
this initialization?
Ideally I'd want to be able to load, use and unload pixman, cairo and any
library repeatedly with no bugs/leaks/crashes.


>
> - If/when we get serious about multithreading in pixman, we'd likely
>   need support for condition variables, and on Linux possibly handroll
>   the thread primitives based on futex() and clone() without using
>   pthreads.
>

Simpleops already provides C11-like condition variables
(cnd_{destroy,init,signal,timedwait,wait} are already implemented,
cnd_broadcast is not, but it should be trivial to add it if needed).
It should also be possible to avoid pthread and use syscalls directly, but
why should that be needed? Is pthread very inefficient on linux?

Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20131002/5da26c1b/attachment.html>