Related
I am confused about the following:
I am hoping to get a job in the field of embedded systems. However, every interview I've had seems to end up with a conversation about threads in C and how to do thread-safe programming
My question is how do I go about learning multithreading in embedded systems? Are they the same as POSIX threads? For example, the tasks in FreeRTOS. Are they same thing as pthreads?
Can someone give me some tips on what to do and where to start?
Every OS has it's own threads/task/processes characteristics.
Despite the differences, the methods to synchronize, guard and interchange data between those, are roughly the same.
If someone knows that you don't know a specific OS, invited you to an interview - he/she probably expects you to answer in general and not to be OS specific.
You can solve any problem with POSIX (or any other) tool-set in mind and to mention that migration of the solution to a non-POSIX environment will keep same logic with some minor adaptations.
Multithreading concept is almost same everywhere, whether in RTOS or Linux.
The difference is in the operational behavior.
My question is how do I go about learning multithreading in embedded
systems?
My suggestion is to first learn and understand the concepts of multithreading by referring some online material, you can practice by writing some simple codes on your desktop running any flavor of Linux.
The go for some advanced topics like synchronization mechanism using Semaphore and Mutexes, you will then get to learn about the basic concept of when to use a semaphore and when to use a mutex for thread synchronization.
Then move to some Embedded Targets and try out some code using uCOS-II/uCOS-III or FreeRTOS.
Are they the same as POSIX threads?
No, they are not exactly same, POSIX thread library is a bit advance and is highly portable on different OS. For e.g. a multithread code written on Linux using pthread can also be compiled and executed on Windows with little or no change.
On the other hand, a thread implementation on RTOS is different, threads in RTOS are treated as tasks and they start executing only when a call to start the scheduler is made.
From my own experience trying to find learning resources, I found the the FreeRTOS docs very useful. They have both a reference manual as well as the Mastering the FreeRTOS Kernal doc which includes code snippets and covers topics such as task management, software timers, resource management, and general thread safe programming techniques. I dont think this would be the best place to start out, but once you've familiarized yourself with basics the other answers and comments have mentioned, this could help with the next step of learning by doing.
I am working with OpenCV, an open source image processing library, and due to complexities in my algorithm I need to use multiple threads for video processing.
How multi-threading is done on C++ 98? I know about C++ 11 has a built in support library for threading (std::thread) but my platform (MSVC++ 2010) does not have that. Also I read about Boost library, which is a general purpose extension to C++ STL, has methods for multi-threading. I also know with MSDN support (windows.h) I can create and manage threads for Windows applications. Finally, I found out that Qt library, a cross platform GUI solution, has support for threading.
Is there a naive way (not having any 3rd party libraries) to create a cross-platform multi-threading application?
C++98 does not have any support for threading, neither in the language nor the standard library. You need to use a third party library and you have already listed a number of the main candidates.
OpenCV relies on different external systems for multithreading (or more accurately parallel processing).
Possible options are:
OpenMP (handled at the compiler level);
Intel's TBB (external library);
libdispatch (on systems that support it, like MacOS, iOS, *BSD);
GPGPU approaches with CUDA and OpenCL.
In recent versions of OpenCV these systems are "hidden" behind a parallel_for construct.
All this applies to parallel processing, i.e., data parallel tasks (roughly speaking, process each pixel or row of the input in parallel). If you need application level multithreading (like for example having a master thread and workers) then you need to use frameworks such as POSIX's threads or Qt.
I recommend boost::thread which is (mostly) compatible with std::thread in C++11. It is cross-platform and very mature.
OpenCV's parallelism is internal and does not directly mix with your code, but it may use more resources and cores than you might expect (as a feature), but this might be at the expense of other external processes.
I have written a little python application and here you can see how Task Manager looks during a typical run.
(source: weinzierl.name)
While the application is perfectly multithreaded, unsurprisingly it uses only one CPU core.
Regardless of the fact that most modern scripting languages support multithreading, scripts can run on one CPU core only.
Ruby, Python, Lua, PHP all can only run on a single core.
Even Erlang, which is said to be especially good for concurrent programming, is affected.
Is there a scripting language that has built in
support for threads that are not confined to a single core?
WRAP UP
Answers were not quite what I expected, but the TCL answer comes close.
I'd like to add perl, which (much like TCL) has interpreter-based threads.
Jython, IronPython and Groovy fall under the umbrella of combining a proven language with the proven virtual machine of another language. Thanks for your hints in this
direction.
I chose Aiden Bell's answer as Accepted Answer.
He does not suggest a particular language but his remark was most insightful to me.
You seem use a definition of "scripting language" that may raise a few eyebrows, and I don't know what that implies about your other requirements.
Anyway, have you considered TCL? It will do what you want, I believe.
Since you are including fairly general purpose languages in your list, I don't know how heavy an implementation is acceptable to you. I'd be surprised if one of the zillion Scheme implementations doesn't to native threads, but off the top of my head, I can only remember the MzScheme used to but I seem to remember support was dropped. Certainly some of the Common LISP implementations do this well. If Embeddable Common Lisp (ECL) does, it might work for you. I don't use it though so I'm not sure what the state of it's threading support is, and this may of course depend on platform.
Update Also, if I recall correctly, GHC Haskell doesn't do quite what you are asking, but may do effectively what you want since, again, as I recall, it will spin of a native thread per core or so and then run its threads across those....
You can freely multi-thread with the Python language in implementations such as Jython (on the JVM, as #Reginaldo mention Groovy is) and IronPython (on .NET). For the classical CPython implementation of the Python language, as #Dan's comment mentions, multiprocessing (rather than threading) is the way to freely use as many cores as you have available
Thread syntax may be static, but implementation across operating systems and virtual machines may change
Your scripting language may use true threading on one OS and fake-threads on another.
If you have performance requirements, it might be worth looking to ensure that the scripted threads fall through to the most beneficial layer in the OS. Userspace threads will be faster, but for largely blocking thread activity kernel threads will be better.
As Groovy is based on the Java virtual machine, you get support for true threads.
F# on .NET 4 has excellent support for parallel programming and extremely good performance as well as support for .fsx files that are specifically designed for scripting. I do all my scripting using F#.
An answer for this question has already been accepted, but just to add that besides tcl, the only other interpreted scripting language that I know of that supports multithreading and thread-safe programming is Qore.
Qore was designed from the bottom up to support multithreading; every aspect of the language is thread-safe; the language was designed to support SMP scalability and multithreading natively. For example, you can use the background operator to start a new thread or the ThreadPool class to manage a pool of threads. Qore will also throw exceptions with common thread errors so that threading errors (like potential deadlocks or errors with threading APIs like trying to grab a lock that's already held by the current thread) are immediately visible to the programmer.
Qore additionally supports and thread resources; for example, a DatasourcePool allocation is treated as a thread-local resource; if you forget to commit or roll back a transaction before you end your thread, the thread resource handling for the DatasourcePool class will roll back the transaction automatically and throw an exception with user-friendly information about the problem and how it was solved.
Maybe it could be useful for you - an overview of Qore's features is here: Why use Qore?.
CSScript in combination with Parallel Extensions shouldn't be a bad option. You write your code in pure C# and then run it as a script.
It is not related to the threading mechanism. The problem is that (for example in python) you have to get interpreter instance to run the script. To acquire the interpreter you have to lock it as it is going to keep the reference count and etc and need to avoid concurrent access to this objects. Python uses pthread and they are real threads but when you are working with python objects just one thread is running an others waiting. They call this GIL (Global Interpreter Lock) and it is the main problem that makes real parallelism impossible inside a process.
https://wiki.python.org/moin/GlobalInterpreterLock
The other scripting languages may have kind of the same problem.
Guile supports POSIX threads which I believe are hardware threads.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I'm wondering which languages support (or don't support) native multithreading, and perhaps get some details about the implementation. Hopefully we can produce a complete overview of this specific functionality.
Erlang has built-in support for concurrent programming.
Strictly speaking, Erlang processe are greenlets. But the language and virtual machine are designed from the ground up to support concurrency. The language has specific control structures for asynchronous inter-process messaging.
In Python, greenlet is a third-party package that provides lightweight threads and channel-based messaging. But it does not bear the comparison with Erlang.
I suppose that the list of languages that are higher-level than Haskell is pretty short, and it has pretty good support for concurrency and parallelism.
With CPython, one has to remember about the GIL. To summarize: only one processor is used, even on multiprocessor machines. There are multiple ways around this, as the comment shows.
Older versions of C and C++ (namely, C89, C99, C++98, and C++03) have no support at all in the core language, although libraries such as POSIX threads are available for pretty much every platform in common user today.
The newest versions of C and C++, C11 and C++11, do have built-in threading support in the language, but it's an optional feature of C11, so implementations such as single-core embedded systems can choose not to support it while supporting the rest of C11 if they desire.
Delphi/FreePascal also has support for threads.
I'll assume, from other answers, that it's only native on the Windows platforms.
Some nice libraries that implement better features on top of the TThread Object:
OmniThreadLibrary
BMThread
Clojure is an up and coming Lisp-dialect for the JVM that is specifically designed to handle concurrency well.
It features a functional style API, some very efficient implementations of various immutable data structures, and agent system (bit like actors in Scala and processes in Erlang). It even has software transactional memory.
All in all, Clojure goes to great lenght to help you write correct multithreaded and concurrent code.
I believe that the official squeak VM does not support native (OS) threads, but that the Gemstone version does.
(Feel free to edit this if not correct).
You need to define "native" in this context.
Java claims some sort of built-in multithreading, but is just based on coarse grained locking and some library support. At this moment, it is not more 'native' than C with the POSIX threads. The next version of C++ (0x) will include a threading library as well.
I know Java and C# support multithreading and that the next version of C++ will support it directly... (The planned implementation is available as part of the boost.org libraries...)
Boost::thread is great, I'm not sure whether you can say its part of the language though. It depends if you consider the CRT/STL/Boost to be 'part' of C++, or an optional add-on library.
(otherwise practically no language has native threading as they're all a feature of the OS).
This question doesn't make sense: whether a particular implementation chooses to implement threads as native threads or green threads has nothing to do with the language, that is an internal implementation detail.
There are Java implementations that use native threads and Java implementations that use green threads.
There are Ruby implementations that use native threads and Ruby implementations that use green threads.
There are Python implementations that use native threads and Python implementations that use green threads.
There are even POSIX Thread implementations that use green threads, e.g. the old LinuxThreads library or the GNU pth library.
And just because an implementation uses native threads doesn't mean that these threads can actually run in parallel; many implementations use a Global Interpreter Lock to ensure only one thread can run at a time. On the other hand, using green threads doesn't mean that they can't run in parallel: the BEAM Erlang VM for example can schedule its green threads (more precisely green processes) across mulitple CPU cores, the same is planned for the Rubinius Ruby VM.
Perl doesn't usefully support native threads.
Yes, there is a Perl threads module, and yes it uses native platform threads in its implementation. The problem is, it isn't very useful in the general case.
When you create a new thread using Perl threads, it copies the entire state of the Perl interpreter. This is very slow and uses lots of RAM. In fact it's probably slower than using fork() on Unix, as the latter uses copy-on-write and Perl threads do not.
But in general each language has its own threading model, some are different from others. Python (mostly) uses native platform threads but has a big lock which ensures that only one runs (Python code) at once. This actually has some advantages.
Aren't threads out of fashion these days in favour of processes? (Think Google Chrome, IE8)
I made a multithreading extension for Lua recently, called Lua Lanes. It merges multithreading concepts so naturally to the language, that I would not see 'built in' multithreading being any better.
For the record, Lua's built in co-operative multithreading (coroutines) can often also be used. With or without Lanes.
Lanes has no GIL, and runs code in separate Lua universes per thread. Thus, unless your C libraries would crash, it is immune to the problems associated with thread usage. In fact, the concept is more like processes and message passing, although only one OS process is used.
Finally Go is here with multi-threading with its own pkg Goroutine.
People say it is on the structure of C-language.
It is also easy to use and understand .
Perl and Python do. Ruby is working on it, but the threads in Ruby 1.8 are not really threads.
What libraries exist for other programming languages to provide an Erlang-style concurrency model (processes, mailboxes, pattern-matching receive, etc.)?
Note: I am specifically interested in things that are intended to be similar to Erlang, not just any threading or queueing library.
Ulf Wiger had a great post recently on this topic - here are the properties he defines as required before you can call something "Erlang Style Concurrency":
Fast process creation/destruction
Ability to support >> 10 000 concurrent processes with largely unchanged characteristics.
Fast asynchronous message passing.
Copying message-passing semantics (share-nothing concurrency).
Process monitoring.
Selective message reception.
Number 2 above is the hardest to support in VMs and language implementations that weren't initially designed for concurrency. This is not to knock Erlang-ish concurrency implementations in other languages, but a lot of Erlang's value comes from being able to create millions of processes, which is pretty damn hard if the process abstraction has a 1-1 relationship with an OS-level thread or process. Ulf has a lot more on this in the link above.
Message Passing Interface (MPI) (http://www-unix.mcs.anl.gov/mpi/) is a highly scalable and robust library for parallel programming, geared original towards C but now available in several flavors http://en.wikipedia.org/wiki/Message_Passing_Interface#Implementations. While the library doesn't introduce new syntax, it provides a communication protocol to orchestrate the sharing of data between routines which are parallelizable.
Traditionally, it is used in large cluster computing rather than on a single system for concurrency, although multi-core systems can certainly take advantage of this library.
Another interesting solution to the problem of parallel programming is OpenMP, which is an attempt to provide a portable extension on various platforms to provide hints to the compiler about what sections of code are easily parallelizable.
For example (http://en.wikipedia.org/wiki/OpenMP#Work-sharing_constructs):
#define N 100000
int main(int argc, char *argv[])
{
int i, a[N];
#pragma omp parallel for
for (i=0;i<N;i++)
a[i]= 2*i;
return 0;
}
There are advantages and disadvantages to both, of course, but the former has proven to be extremely successful in academia and other heavy scientific computing applications. YMMV.
Microsoft Concurrency and Coordination Runtime for .NET.
The CCR is appropriate for an
application model that separates
components into pieces that can
interact only through messages.
Components in this model need means to
coordinate between messages, deal with
complex failure scenarios, and
effectively deal with asynchronous
programming.
Scala supports actors. But I would not call scala intentionally similar to Erlang.
Nonetheless scala is absolutely worth taking a look!
Also kilim is a library for java, that brings erlang style message passing/actors to the Java language.
Mike Rettig created a .NET library called Retlang and a Java port called Jetlang that is inspired by Erlang's concurrency model.
Termite for Gambit Scheme.
Microsoft's Not-Production-Ready Answer to Erlang: Microsoft Axum
If you are using Ruby, take a look at Revactor.
Revactor is an Actor model implementation for Ruby 1.9 built on top of the Rev high performance event library. Revactor is primarily designed for writing Erlang-like network services and tools.
Take a look at this code sample:
myactor = Actor.spawn do
Actor.receive do |filter|
filter.when(:dog) { puts "I got a dog!" }
end
end
Revactor only runs on Ruby 1.9. I believe the author of the library has discontinued maintaining it but the documentation on their site is very good.
You might also want to take a look at Reia: a ruby-like scripting language built on top of the Erlang VM. Reia is the new project of the creator of Revactor: Tony Arcieri.
For python you can try using processing module.
Warning: shameless plug!
I developed a library for this kind of message passing in Haskell:
Erlang-style Distributed Haskell.
Volker
JoCaml extends OCaml with join calculus for concurrent and distributed programming.
Akka (http://akka.io) is heavily influenced by erlangs OTP. It has built on scala's actors and is great for concurrency on the JVM.