Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add implementations based on C11/C++11 standard thread libraries #42

Closed
Bulat-Ziganshin opened this issue Feb 13, 2017 · 8 comments

Comments

@Bulat-Ziganshin
Copy link

commented Feb 13, 2017

It will allow to use library on non-Windows/Posix plaforms, increasing the portability to maximum possible without serious work. And easy to implement since both standards looks like a pthread with renamed functions.

@nemequ

This comment has been minimized.

Copy link
Contributor

commented Feb 13, 2017

That should already be possible, though the ordering is reversed. TinyCThread is an implementation of the C11 thread library; if your libc provides a C11 thread library you can just use that instead of TinyCThread. i.e.,

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L) && !defined(__STDC_NO_THREADS__)
#  include <threads.h>
#else
#  include <tinycthread.h>
#endif

@nemequ nemequ closed this Feb 13, 2017

@nemequ

This comment has been minimized.

Copy link
Contributor

commented Feb 13, 2017

FWIW, I do intend to add an OpenMP backend when I have time.

@Bulat-Ziganshin

This comment has been minimized.

Copy link
Author

commented Feb 13, 2017

oh, i really missed that! btw, i prefer http://en.cppreference.com/w/c/thread as documentation, you can include that url in the doc as recommended way to learn the libary usage

also i propose to include this #if snippet of code into readme to show the preferred way to use the library

what about C++11 support? are there compilers that miss C11 but implement C++11?

How OpenMP backend could be useful? Is it for compilers that has OpenMP, but no posix/win/c11 api? Or it will be more efficent is some circumstances?

@nemequ

This comment has been minimized.

Copy link
Contributor

commented Feb 13, 2017

i prefer http://en.cppreference.com/w/c/thread as documentation, you can include that url in the doc as recommended way to learn the libary usage

That looks like a pretty good resource, I can add a link to the web site.

what about C++11 support? are there compilers that miss C11 but implement C++11?

Almost nobody has implemented C11 threads (AFAIK only musl and Pelles do), so yes. I'm not sure it would be a good idea, though… I doubt many people would be willing to pull in C++ just for threads, and those who are willing would probably be happy using C++11 threads directly (or using something like TinyThread++). It would also complicate the build process; right now there is just a single C file to drop into your build system, but C++ would probably mean another file and code in the build system to handle switching. And just switching the C file over to C++ would force most projects to require a C++ compiler. Basically, a lot of trouble for not many people (honestly, pthreads + Windows covers almost everyone).

How OpenMP backend could be useful? Is it for compilers that has OpenMP, but no posix/win/c11 api? Or it will be more efficent is some circumstances?

Mostly it would just be another backend. I'm not too familiar with any OpenMP implementation internals, but I could definitely see it being more efficient for projects which already use OpenMP; for example, maybe blocking a thread using the existing APIs doesn't free up a worker for OpenMP, but going through the OpenMP API might.

AFAIK OpenMP is usually built on lower-level routines (pthreads or Win32 API), so I doubt it would be more efficient for programs which don't already use OpenMP.

@Bulat-Ziganshin

This comment has been minimized.

Copy link
Author

commented Feb 13, 2017

this Issue was created for https://encode.ru/threads/2119-Zstandard?p=51747&viewfull=1#post51747

it's usecase i imagine - library implemented in pure C and need some m/t features. The best way is to offload this layer to library like TinyCThread. But while ZSTD itself implemented in pure C, most clients will be able to use C++. So support of C++11 threads will improve portability unless all compliers supporting C++11 threads, are also implement C11 threads. I have no idea whether it's true or not. I hope you know or can look into that :)

C++11 implementation should be not harder than OpenMP one and will be more useful imho, if that improves compiler support.

OpenMP implementation may improve performance, but probably not the portability.

@nemequ

This comment has been minimized.

Copy link
Contributor

commented Feb 13, 2017

I'm not sure how much C++11 would improve portability, either. The vast majority of users are covered by pthreads + Win32.

Like I said, there are some issues with using C++. The way I see it there are two possibilities:

  • Rename tinycthread.c to tinycthread.cc, and implement the C++ back-end just like pthreads and win32 are.
  • Provide separate files for each backend (i.e., tinycthread-posix.c, tinycthread-windows.c, tinycthread-cpp11.cc

The first option requires everyone using tinycthread to have a C++ compiler, even if they just want to use one of the C back-ends. IMHO that's completely unacceptable.

The second option requires moving the logic to choose an implementation into the build system, and requires a C++ compiler (though only if they want the C++11 back-end to be an option). One of the things people really like about TinyCThread is that it's just a single source and a single header to add to their project so it's very easy to integrate.

Completely discounting the effort of writing a C++11 back-end (I think you're right, it would be pretty easy), I still don't think option 2 is worth the drawbacks. Given that almost everyone has access to either pthreads or win32 threads, I think the number of people who would benefit from a C++11 back-end would be pretty low.

Basically, I think the best thing to do here is wait and see. If we start getting reports of platforms where TinyCThread doesn't currently work (I've personally tested TinyCThread on Linux, OS X, Windows, BSD, and Solaris) then I'd be happy to discuss the best way to support that platform, and maybe that will be C++11. Or maybe it will be a proprietary API, or OpenMP, Cilk, OpenACC, etc. But I definitely don't want to compromise the experience for developers to add an unnecessary back-end.

@Bulat-Ziganshin

This comment has been minimized.

Copy link
Author

commented Feb 14, 2017

My goal was to ensure that i can recommend using TinyCThread to projects like zstd and they will not become less portable by choosing this way. As far as you are interested in adding new backends at user requests and appreciate the fact that your new users may be not pure C programmers, but C++ programmers that just need to use intermediate pure C library, such as zstd, it's fine.

I just want to be able to say "please use TinyCThread, it will both make your application more portable AND reduce your work to ensure portability" and move the portability headache from zstd/whatever developer to your side

Speaking about concrete implementation, i think that it may be .cc file with a cmake logic to select between TinyCThread.c and TinyCThread.cc at compile time

I'm not sure how much C++11 would improve portability, either. The vast majority of users are covered by pthreads + Win32.

If now most of TinyCThread users are direct users (i.e pure C programmers), pthreads/win32 support may be enough. I fear that ZSTD userbase may be much wider (and in particular, most of its users use C++) and include pretty exotic platforms. So, outsorcing support of such platfroms to actively maintained 3rd party libraries will make zstd project stronger (by freeing developer resources), while outsorcing to stalled 3rd party libraries will make it weaker. That's my whole point. I don't ask porting to something, but to be READY to port to anything.

@nemequ

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2017

That sounds quite reasonable.

I think you should be comfortable using TinyCThread. I'm interested in supporting as many platforms as we can… I can't promise I will always have time (or expertise, or access to the platform in question) to do a port myself, but I'm always happy to accept patches as long as the quality is sufficient. Worst case scenario is that you shouldn't be any worse off using TinyCThread than with you would be with a custom abstraction layer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.