I am looking for good books/resources for introducing how to use the thread library with C++0x. I have searched amazon.com and SO without informative post.
I asked a similar question myself recently: Where can I find good, solid documentation for the C++0x synchronization primitives?
And I got back a fantastic answer: C++ Concurrency in Action by Anthony Williams
The JustThread library at the end of that link also has good Doxygen documentation as well as implementations of a lot of the C++ threading stuff, though it's a commercial library :-/.
Lastly, you can get a pre-release PDF of this book. I've gotten it myself, and I can tell you that it's a pretty good book.
gcc/g++ implements more of this than they let on. While it's not yet complete, they have a decent implementation of the classes for threads and futures and they also implement the atomic family of classes which allow for some fairly fine-grained synchronization that you would normally only be able to achieve by somehow getting memory barrier instructions into your code by hand.
Right now there are very few (at least not gcc) that support the thread section of C++0x.
Therefore you have to use boost which closely follows the C++0x specification.
I find that the best resource for using boost libraries is their own online documentation, which can be found at http://www.boost.org/doc/libs/1_47_0/doc/html/thread.html.
Related
As far as I understand libgreen is not a part of Rust standard library anymore. Also I can't find a separate libgreen package. There are a few alternatives - coroutine, which does not provide actual green threads for now, and green-rs, which is broken. Do I right understand that for now there is no lightweight Go-like processes in Rust?
You are correct that there's no lightweight tasking library in std (or the rest of the main distribution), that green doesn't compile and that coroutine doesn't seem to fully handle the threading aspect yet. I do not know of any other library in this space.
As for what happened: the RFC linked to by that issue—RFC 230—is the canonical source of information. The summary is that it was found that the method by which green threading/IO was handled (std tried to abstract across both models, allowing them to be used interoperably automagically) was not worth the downsides. Now, std aims to just provide a minimum base-line of useful support: for IO/threading, that means "thin", safe wrappers for operating system functionality.
Read this https://aturon.github.io/blog/2016/08/11/futures/ and also:
Steve Klabnik's response in the comments:
In the beginning, Rust had only green threads. Eventually, it was
decided that a systems language without systems threads is... strange.
So we needed to add them. Why not add choice? Since the interfaces
could be the same, why not abstract over them, and you could just
choose which one you wanted?
At the same time, the problems with green threads by default were
becoming issues. Segmented stacks cause slow C interop. You need a
runtime to manage them, etc. Furthermore, the overall abstraction was
causing an unacceptable cost. The green threads weren't very green.
Plus, with the need to actually release someday looming, decisions
needed to be made regarding tradeoffs. And since Rust is supposed to
be a systems language, having 1:1 threads and basically no runtime
makes more sense than N:M threads and a runtime. . So libgreen was
removed, the interface was re-done to be 1:1 thread centric.
The 'release someday looming' is a big part of it. We want to be
really stable with Rust, and with all the things to do to actually
ship a 1.0, we didn't want to crystallize an interface we weren't
happy with. Heck, we pulled out a lot of libraries that are even less
important for similar reasons, like rand. Engineering is all about
tradeoffs, and we decided to choose minimalism.
mio is a non starter for us, as are most of the other async i/o frameworks for Rust, because we need Windows and besides we don't want
to get locked into an expensive to replace library which may get
orphaned.
Totally understood here, especially in the general case. In the
specific case, mio is going to either have Windows support, or a
windows-specific version of mio is going to be released, with a
higher-level package providing the features for all platforms. And in
this case, it's maintained by one of the people who's currently using
Rust heavily in production, so it's not likely to go away anytime
soon. But, unless you're actively involved, it's hard to know things
like that, which is, of itself an issue.
One of the reasons we were comfortable removing libgreen is that you
can write your own libraries to do different kinds of IO. 1.0 is a
strong core that we feel good about stabilizing forever, not the final
bit. Libraries like https://github.com/carllerche/mio can test out
different ways of handling things like async IO, and, when they're
mature enough, we can always pull them back in the standard library if
need be. But in the meantime, it's just one line to your Cargo.toml to
add them in.
And such text from reddit:
Unfortunately they ended up canning the greenlet support because
theirs were slower than kernel threads which in turn demonstrates
someone didn’t understand how to get a language compiler to generate
stackless coroutines effectively (not surprising, the number of
engineers wired the right way is not many in this world, but see
http://www.reddit.com/r/rust/comments/2l0a4b/do_rust_web_servers_use_libuv_through_libgreen_or/
for more detail). And they canned the async i/o because libuv is
“slow” (which it is only because it is single threaded only, plus
forces a malloc + free per async operation as the buffers must last
until completion occurs, plus it enforces a penalty over synchronous
i/o see
http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html),
which was a real shame - they should have taken the opportunity to
replace libuv with something better (hint: ASIO + AFIO, and yes I know
they are both C++, but Rust could do with much better C++ interop than
the presently none it currently has) instead of canning
always-async-everything in what could have been an amazing step up
from C++ with most of the benefits of Erlang without the disadvantages
of Erlang.
For newcomers, there is now may, a crate that implements green threads similar to goroutines.
As question says it all I was looking for in depth explanation of data-dependency barrier in SMP especially with respect to Linux Kernel. I have the definition and brief description handy in this link here.
Linux Kernel Memory Barriers Documentation
However I was attempting to get a profound understanding of this concept. Your thoughts and inputs are highly appreciated.
Actually, at least in terms of C++11, this is more closely related to consume semantics. You can read more about it e.g. here. In short, they provide weaker guarantees than acquire semantics, which makes them more efficient on certain platforms that support data dependency ordering.
In C++ terms, it is called memory_order_consume. See this presentation from Paul Mckenney.
Old answer: I believe "acquire semantics" is the more commonly used term for what the document is calling a "data-dependency barrier". See for example this presentation or the C++11 memory_order_acquire.
Update: per comments, the Linux description for Data Dependency Barriers sounds more like C++ "consume semantics".
This question is about design / is fairly open-ended.
I'd like to use OpenCV, a large C++ library, from Haskell.
The closest solution at the moment is probably Arjun Comar's attempt to adapt the Python / Java binding generator.
See here, here, and here.
His approach generates a C interface, which is then wrapped using hsc2hs.
Due to OpenCV's lack of referential transparency in its API, as well as its frequent use of call parameters for output, for Arjun's approach to fully succeed he'll need to define a new API for OpenCV, and implement it in terms of the existing one.
So, it seems it might not be too much extra work to go whole-hog and define an API using an interface description languages (IDL), such as SWIG, protobuf-with-RPC, or Apache Thrift.
This would provide interfaces to a number of languages besides Haskell.
My questions:
Is there anything better than SWIG for a server-free solution?
(I just want to call into C++; I'd rather not go through a local server.)
If there's no good server-free solution, should I use protobuf-with-RPC or Thrift?
Related: How good is Thrift's Haskell support?
From the code, it looks like it needs updating (I see references to GHC 6).
Related: What's a good protobuf-with-RPC solution?
With Apache Thrift, you get Haskell support. You are correct, code is not generally "latest", but you rarely care. You can do complex things on other abstraction levels and keep things as simple as possible at messaging level.
Google Protobuf has no support for Haskell, nor does SWIG. With Protobuf you get C++, Java, JavaScript and Python, to my knowledge the main languages at Google. Have a look at this presentation. Without contest, Thrift and Protobuf are the best in house.
It seems in your case you have to go with Thrift, as it supports Haskell.
It sounds like the foreign function interface for C++ is what you want:
Hackage,
Github
Disclaimer: I haven't used it, only heard good things about it.
I've been coding for some time, and I always thought the linking phase of compilation was pretty straight forward, but recently I had to add a plugin system to an app, and I ran into quite a few compilation and runtime problems, due to my complete lack of knowledge on the matter. I've now got it working fine and learned a lot in the process, but now that I' aware I still have a lot to learn on the subject, I wanted to explore the subject more. So I was wondering if anyone had good pointers on articles, blog posts, or books on the whole "code sections, symbols, linking, dynamic/static libraries..." business.
I'm developing on Linux using gcc and ld, but I'm also interested in the M$ way of doing things, I thirst for knowledge :)
Thanks!
Here are some good online resources:
Static, Shared Dynamic and Loadable Linux Libraries
Program Library HOWTO
Ulrich Drepper (maintainer of glibc) provides a very thorough description of the linux implementation of shared libraries in his paper How To Write Shared Libraries, definitely worth a read if you want to know the nitty-gritty details. I actually can't think of a book that does a great job covering the details.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
With the rise of multicore CPUs on the desktop, multithreading skills will become a valuable asset for programmers. Can you recommend some good resources (books, tutorials, websites, etc.) for a programmer who is looking to learn about threaded programming?
Take a look at Herb Sutter's "The Free Lunch Is Over" and then his series of articles on Effective Concurrency.
Joseph Albahari wrote a good overview of Threading in C# here:
http://www.albahari.com/threading/
I've honestly never read it myself, but Concurrent Programming in Java is a book I've heard recommended by several people.
http://www.yoda.arachsys.com/csharp/threads/
I write about multithreading and concurrency in C++ on my blog. I'm also writing a book on concurrency in C++: C++ Concurrency in Action.
I've read (most of) Java Concurrency in Practice by Brian Goetz, which is very good.
There is obviously a Java-based theme running through the book (using Java specific implementations of threads, locks etc.), but pretty much all of the principles can be applied to other languages.
The author's home page contains a list of articles he has written, some of which include threading related stuff. Maybe start there and if you like his style, buy the book.
For a great guide and reference for concurrency programming in C# (or .NET in general) I'd recommend the MSDN What Every Dev Must Know About Multithreaded Apps article by Vance Morrison on MSDN. It contains a great deal of best-practice information and caveats about multithread development
I maintain a linkblog for concurrency articles, blogs, and projects at:
http://concurrency.tumblr.com
I usually post a link or two per day on a variety of topics (threads, actors, locking, parallel programming) in a variety of environments (Erlang, Java, Scala, .NET, C++, Ruby, Python, etc).
It's Delphi specific, but no reason why the concept wouldn't apply to any other language!
Multi Threading Tutorial
http://www.cilk.com/multicore-e-book/
That's a nice general overview of the sitution, if you're looking for tuorials and books it might be best to specify a language as a starting point so you can mess around with some code.
The Erlang programming language provides an easy-to-use style of concurrent programming. You may never actually use Erlang, but the concepts are transportable to other languages. You might want to read the book Programming Erlang: Software for a Concurrent World .
Fans of functional programming claim that there is no need to learn anything new. Just use a pure functional language, and the compiler or interpreter will automatically parallelize everything. So you might want to learn Haskell, OCaml, or another functional language.
I don't know what exactly you are looking for, but if you are doing WindowsForms development the following blog post is worth every minute reading:
WinForms UI Thread Invokes: An In-Depth Review of Invoke/BeginInvoke/InvokeRequred
I think Boost.Threads is a great C++ concurrency library to learn, especially if you just want to get started in writing multithreaded applications. The code is very succinct and easy to understand, plus the next C++ standard will likely include a threading library based on Boost.Threads (tutorial: http://www.ddj.com/cpp/184401518)
If you want to have a go at doing a highly parallel version of a simple task, or see real solutions, you could do worse than look at the wide finder project. Basically it's about how to do parallel regex matching of log files efficiently, but trying to add as little code as possible.
Participants have submitted solutions in many different languages and the performance results are posted. The original project has now finished and there is now wide finder 2 taking the work on.
CodingHorror has a good introduction to wide finder.
For a rich, thorough treatment of the subject, with a good balance between computer science and practice, I recommend The Art of Multiprocessor Programming. A lot of examples are in object-oriented code, i.e. Java, with other languages scattered throughout. It just depends on the topic being covered. What I really love about this book is that it discusses how common algorithms should be implemented in a concurrent design. Of course, there's so much more!
For general concepts and a treatment of pthreads, I really like Programming with POSIX Threads. Being the library and API that it is, it's in C.
For Windows and C# developers, check out Joe Duffy's blog. Joe works on parallel libraries, infrastructure, and programming models in Microsoft's Developer Division. He has a book coming in Nov. 2008 titled Concurrent Programming on Windows (Amazon link).
Also, don't miss the Godfather's blog: Herb Sutter's Sutter's Mill. He has links to all his articles in Dr. Dobb's Journal and more. Click his Concurrency category.
CPU manufacturers websites have some interesting content:
http://developer.amd.com/documentation/articles/Pages/default.aspx#parallel
http://software.intel.com/en-us/multi-core
Also Intel's opensource threading library has some good references:
http://www.threadingbuildingblocks.org/
If you work with C#, the book "C# 2008 and 2005 threaded programming", by Gaston C. Hillar - Packt Publishing - http://www.packtpub.com/beginners-guide-for-C-sharp-2008-and-2005-threaded-programming/book , will help you.
Highly recommended for C# programmers, because you can download the code with funny examples that exploit your multicore computer.
The book is a nice guide with a lot of code to practice. It tells stories while it explains the most difficult concepts.