I'll be working on a project in concurrent programming, and it would be nice to be able to use Scheme. However, for this project it will be really necessary to use different CPU cores (continuation-based threads won't do).
So, is there some R5RS Scheme that implements SRFI-18 making use of different CPU cores?
Guile 2.0 has a SRFI 18 implementation that uses POSIX threads. (Guile 1.8 had POSIX threads, but no SRFI 18.)
Better late than never:
bigloo supports srfi-18 and POSIX-threads
Chicken Scheme compiles to C and supports SRFI-18 (although you should read the notes section!).
Related
I want to learn multi-threading in C++ but I'm not sure what type would be most useful. The ones I've seen tutorials on are:
Windows native calls
OpenMP
Boost
(I'm sure that there are probably more.)
What is each one's key features and what are they best used for?
Note: I've already done some multi-threading in C# by manually creating the threads, and more complexity of the threading will just make it more fun. :)
I'd start with pthreads if you have more of a C background, or Boost Thread if you are accustomed to more idiomatic C++. Either is reasonably portable and widely used.
How about TBB? It is portable and has easy to use parallel template patterns, concurrent containers, task scheduler and scalable memory allocaturs. TBB will let you manage threads directly, but that is not necessary in most of the cases.
Personally I would stay away from platform specific threads, unless there an urgent need to do something, well, platform specific.
Boost threads is portable and easy to use, but does have neither parallel patterns nor concurrent containers. You would need to manager threads manually, which can get ugly pretty quickly.
PThreads isn't available on Windows and its C. You really want to do multi-threading in C++, not C. RAII mixes well with mutexes and scoped locks.
Another option is PPL in Visual C++ 2010. It is similar to TBB, but as you may guess available for Windows only.
OpenMP is easy to use, but not very flexible. Since you already learned C++, you should use something more serious, such as TBB or PPL. For some strange reason Visual C++ 2010 doesn't support OpenMP 3. Too bad.
If you want to be portable, learn Posix threads. You know, all thread libraries provide more or less the same set of features, so it's up to you, but Posix will give you the basis.
openMP isn't exactly "multi-threading" as you mean it.
WinThreads (Windows) and pthreads (Linux) are POSIX threads and represent probably your best choice to get started. It is important to learn the distinction between processes and threads, then learn about the various memory access models that are associated with them. Next, try concurrency approaches like OpenMP and MPI "threads".
There are some basic concepts that will get repeated. Learn them well.
With the advent of threading facilities in the STL for the new C++ standard (C++0x), will it be better to change existing code that is using POSIX threading or even Windows threading to use STL threading?
You could always hedge your bets... write your own simple threading API that is just featureful enough to do what your application needs to be done, and change your code to target your threading API only. Then you can implement the internals of your custom threading API using Windows or Posix or STL or whatever, and change the implementation whenever you need to without having to touch your entire codebase each time.
By doing it that way, you could start with the STL implementation, and then if it turns out that e.g. Windows has a difficult-to-resolve problem using that, you could just include an alternate Windows-API implementation inside my_threading_api.cpp (inside of an #ifdef WIN32) and you'd be back in business.
A great deal will depend on how much you care about portability, and how much you're taking advantage of features your native API may provide that the standard library doesn't. The standard library threading is sufficiently similar to POSIX that (at least offhand) I can't think of much you'd gain by staying with POSIX (and due to the similarity, porting to use the standard library should usually be pretty easy).
Windows threading is enough different that you're more likely to run into something that will be non-trivial to port to using the standard library, and even at best porting will probably be non-trivial.
Don't change unless you really need it. I assume that your existing code is working well.
There's no telling how long it will be before the C++0x library features are commonly supported, so the answer might well depend on how tied to a particular compiler you might want to be.
You might also want to consider a framework or library that works on top of the native or C++0x library implementation, such as Boost Threads or the Intel Threading Building Blocks and let that library handle the details of whether it's using C++0x features or platform APIs.
It depends.
C++0x threading isn't widely supported yet (I think GCC implements it, but MSVC doesn't, and I don't know when they're planning to add that support, but I might suspect they consider it a low priority feature)
If your code works as it is, why change it?
For new C++ applications, and assuming compiler support, I'd go with C++0x threads, simply because they're standard, and it's a much nicer API than either Win32 or POSIX threads.
I am looking for lightweight multi-threading framework for C++. I found POSIX Threads.
Please, share you practical experience with POSIX threads: before I start with it I want to know its pros and cons from real people, not from wiki.
If you practically compared it with anything (maybe, better), it would be interesting to know either.
UPD: cross platform features are really important for me, so I would appreciate this direction described.
UPD2: I already have an experience with one framework for QNX / Win32, but it is not lightweight and - oh, I forgot to mention, - it is commercial, not free, but I need a free one.
I found Boost.Threads to be really nice, especially after the 1.35 rewrite. POSIX threads on Windows is not so trivial, and it's a C API, so I would definitely prefer Boost to it. It has all the stuff you need, is portable and requires little setup.
Another C thread API is GThreads from GLib. There is a 1-to-1 mapping between some gthread and pthread calls such as pthread_create, but gthreads have 2 big features that I have found very useful:
thread pools and
asynchronous queues for sending messages between threads.
The thread pools are very powerful, allowing things like dynamic resizing of the pool. See http://library.gnome.org/devel/glib/2.20/glib-Threads.html
The POSIX threading API is a C API, not C++.
What do you want to use it for? Personally, I find it to be a very clumsy and overly verbose API. But it is your best bet if you want to do cross-platform development on Unix/Linux-like operating systems. It is not natively supported on Windows.
Personally, I would not use a threading or any other OS dependent API directly in your code. Build another abstraction layer on top of it. For example, we built what we call an "OS layer"; a C++ framework for working with threads, semaphores, timers, mutexes, etc. Our code uses this exclusively. Underneath the hood, we have implementations for POSIX, Win32, INTEGRITY, and vxWorks. This lets our code work on a large variety of platforms.
If you don't want to build your own layer, you can look towards reusing many others like Boost, Qt, etc.
I used POSIX a while ago for a program I wrote. It worked fine on Linux and Solaris and it's not terribly complicated to implement. My brother on the other hand is a Windows programmer and preferred boost to Posix. I guess it depends on your target. I found boost to be a bit on the bloated side and had heard bad things about it. My brother thinks it's the greatest thing since sliced bread. I suppose it's a ford vs chevy thing. Everyone will have an opinion.
If you don't like Boost's thread API, then you might want to look at POCO's.
As you are mentioning QNX have a look at ACE. It is a vast framework that is available for many platforms (including QNX).
Others have already mentioned Boost.
You are well advised to use one of these libraries instead of the low level, non portable and error prone C APIs.
Boost threads library is probably your best bet if you work in C++. I had very positive experience with it both on Unix and win32. Avoid ACE - bad design, wrong approach. Also take a look at Intel TBB, though I haven't used it in practice.
I've found it to be pretty similar to the win32 thread API, the only (real) difference you need to be aware of is that win32 mutexes don't block when used on the same thread while posix do. Apart from that, it's a pretty straight forward API.
I am familiar with concurrent programming in Java which provides a lot of tools for this. However, C++ concurrent programming isn't so easy to start using.
What is the best way to start programming concurrently on C++? Are there any nice libraries which wrap concurrent programming primitives and provide you with more high-level constructs?
I tried QtConcurrent which provides you with nice MapReduce functionality but it is heavily biased towards concurrent computation using Qt so it's not a good choice if you don't want to use Qt.
Are there any other similar libraries? What do people use here?
Thanks for your help in advance,
sneg
There are several choices:
ACE which provides some concurrency constructs
Intel Threading Building Blocks
boost::threads
OpenMP
Qt Threading libraries
Morendil's suggestion (CSP - communicating sequential processes) is truly interesting to take a look at - it's a very different view of threading and one that works well once you wrap your head around it. I first encountered it in the rather esoteric Occam language for Transputers, but the idea has stuck with me.
A more conventional idea: boost::threads work quite well for building thread-based concurrent programs. It's quite low level though.
OpenMP is at a higher level than threads and also quite well-supported.
You could look at CSP, which has a C++ implementation. Way different from Java's threading primitives, though.
This question along with the answers can probably help you a little bit.
Intel's Threading Building Blocks is great for introducing concurrency at the level of individual data-parallel loops, and it takes care of managing threads and allocating work automagically. It can be used in similar ways to OpenMP, but without the need for explicit compiler support.
Been doing mostly Java and smattering of .NET for last five years and haven't written any significant C or C++ during that time. So have been away from that scene for a while.
If I want to write a C or C++ program today that does some multi-threading and is source code portable across Windows, Mac OS X, and Linux/Unix - is PThread a good choice?
The C or C++ code won't be doing any GUI, so won't need to worry with any of that.
For the Windows platform, I don't want to bring a lot of Unix baggage, though, in terms of unix emulation runtime libraries. Would prefer a PThread API for Windows that is a thin-as-possible wrapper over existing Windows threading APIs.
ADDENDUM EDIT:
Am leaning toward going with
boost:thread - I also want to be able
to use C++ try/catch exception
handling too. And even though my
program will be rather minimal and not
particularly OOPish, I like to
encapsulate using class and namespace
- as opposed to C disembodied functions.
Well, pthreads is the old posix standard for writing threaded programs. Its the lowest level threading routines, so its a good choice for cross-platform threading.
However, there are alternatives:
boost::thread - an STL style
threading library
Intel's Thread
Building Blocks
OpenMP -
both these are a higher-level way of
writing threaded apps without needing
to do any threading calls.
As the latter are all fully supported on all platforms, (pthreads requires a bit of compiler settings as its only part of Windows posix subsystem, unless you want to use Pthreads-w32), then perhaps the latter ones are a better choice. boost::threads are more like a threading library, the other 2 are high-level ways of achieving parallelism without needing to code 'threads', they allow you to write loops that run concurrently automatically (subject to common-sense conditions)
Boost::thread is not a C compatible library though.
edit: cross-platform abilities of the above:
Intel TBB is cross-platform (Windows*,
Linux*, and Mac OS* X), supports
32-bit and 64-bit applications and
works with Intel, Microsoft and GNU
compilers.
OpenMP depends on the compiler you want to use, but GCC and/or Intel compilers have supported OpenMP Windows, Linux and MacOS.
If you need your code to be truly portable then it may be best to stay away from the various libraries that scatter the internet. At some point you'll find a platform they don't support and will then have to create your own branch.
This is also not a hard problem to solve and can be a good exercise for creating cross-platform code.
I'd suggest you create a class, e.g. CThread, that has separate .cpp implementations for each platform and a pure-virtual execute() function that is called after your thread is constructed/run.
That allows all of your thread-creation and sleep/shutdown/priority code to be implemented using the most appropriate API for the platform. You may also need a header (e.g. ThreadTypes.h) that contains defines/typedefs for each platform.
E.g.
// ThreadTypes.h
#if defined(PLATFORM_WIN) || defined(PLATFORM_XBOX)
typedef DWORD ThreadID
#elif defined(PLATFORM_PS3)
// etc etc
#endif
This is how I have written all my cross-platform threading code for platforms such as PC/PS2/PS3/360/Wii. It is also a good pattern to follow for things like mutex's and semaphores, which if you have threads you're certain to need at some point :)
Nope, pthreads aren't normally available on Windows. (There are a few attempts at implementing it, but it's not supported by the OS directly, at least.)
If you're writing C++, Boost is, as usual, the answer. Boost.Thread has a portable (and safer) threading library.
In C, the simplest solution is probably to wrap write a common wrapper for both pthreads and the Windows threading API.
I will bet on ZThread
Simple API, easier to use than PThreads and FREE
Have a look at ting also:
http://code.google.com/p/ting/
It is cross platform between Windows and Linux. No Mac OS support yet.