Hello everyone!
A.
Usually, it's possible to do but does it works fine as well with Akka Framework?
I mean if is it possible to change the number of Akka's threads dynamically?
B.
Another good question is, can I decide how many threads each node will get?
I mean - can i set the number of threads per node at the start?
Even if you know one answer, bless you!
Well after a little bit more research the answer to those questions is YES.
If someone finds it necessary I found an explanation about it here:
16.4.3. Changing thread pool size statically
https://livebook.manning.com/book/akka-in-action/chapter-16/148
I have a question from one of my IT-subjects. Actually I am trying to understand multithreading, and the one question that I need answer to is
what can be done if we want to activate multiple Threads when our
Hardwaresystem doesn't support explict multithreading solutions
(also don't know what solutions fall into that category.)
Any help on understandig the whole multithreading is welcome and particulary answer on this question :)
Thank you!
I don't believe it makes any sense to talk about implicit multi-threading.
Multi-threading is a way to structure computer software such that a single program can have several different, independent activities going on at the same time. There are several different reasons why you would want to do that, but none of them happens by accident. Multi-threaded programs only exist because somebody intentionally wrote them that way.
One of the reasons for writing a multi-threaded program is to perform parallel computation on a multi-CPU host. Other technologies that you mentioned, "superscalar, SMT, VLIW," are all different approaches to parallelism.
My guess is, that when you said "multithreading" in your question, you actually were asking about parallelism.
It seems that I've finally got to implement some sort of threading into my Delphi 2009 program. If there were only one way to do it, I'd be off and running. But I see several possibilities.
Can anyone explain what's the difference between these and why I'd choose one over another.
The TThread class in Delphi
AsyncCalls by Andreas Hausladen
OmniThreadLibrary by Primoz Gabrijelcic (gabr)
... any others?
Edit:
I have just read an excellent article by Gabr in the March 2010 (No 10) issue of Blaise Pascal Magazine titled "Four Ways to Create a Thread". You do have to subscribe to gain content to the magazine, so by copyright, I can't reproduce anything substantial about it here.
In summary, Gabr describes the difference between using TThreads, direct Windows API calls, Andy's AsyncCalls, and his own OmniThreadLibrary. He does conclude at the end that:
"I'm not saying that you have to choose anything else than the classical Delphi way (TThread) but it is still good to be informed of options you have"
Mghie's answer is very thorough and suggests OmniThreadLibrary may be preferable. But I'm still interested in everyone's opinions about how I (or anyone) should choose their threading method for their application.
And you can add to the list:
. 4. Direct calls to the Windows API
. 5. Misha Charrett's CSI Distributed Application Framework as suggested by LachlanG in his answer.
Conclusion:
I'm probably going to go with OmniThreadLibrary. I like Gabr's work. I used his profiler GPProfile many years ago, and I'm currently using his GPStringHash which is actually part of OTL.
My only concern might be upgrading it to work with 64-bit or Unix/Mac processing once Embarcadero adds that functionality into Delphi.
If you are not experienced with multi-threading you should probably not start with TThread, as it is but a thin layer over native threading. I consider it also to be a little rough around the edges; it has not evolved a lot since the introduction with Delphi 2, mostly changes to allow for Linux compatibility in the Kylix time frame, and to correct the more obvious defects (like fixing the broken MREW class, and finally deprecating Suspend() and Resume() in the latest Delphi version).
Using a simple thread wrapper class basically also causes the developer to focus on a level that is much too low. To make proper use of multiple CPU cores a focus on tasks instead of threads is better, because the partitioning of work with threads does not adapt well to changing requirements and environments - depending on the hardware and the other software running in parallel the optimum number of threads may vary greatly, even at different times on the same system. A library that you pass only chunks of work to, and which schedules them automatically to make best use of the available resources helps a lot in this regard.
AsyncCalls is a good first step to introduce threads into an application. If you have several areas in your program where a number of time-consuming steps need to be performed that are independent of each other, then you can simply execute them asynchronously by passing each of them to AsyncCalls. Even when you have only one such time-consuming action you can execute it asynchronously and simply show a progress UI in the VCL thread, optionally allowing for cancelling the action.
AsyncCalls is IMO not so good for background workers that stay around during the whole program runtime, and it may be impossible to use when some of the objects in your program have thread affinity (like database connections or OLE objects that may have a requirement that all calls happen in the same thread).
What you also need to be aware of is that these asynchronous actions are not of the "fire-and-forget" kind. Every overloaded AsyncCall() function returns an IAsyncCall interface pointer that you may need to keep a reference to if you want to avoid blocking. If you don't keep a reference, then the moment the ref count reaches zero the interface will be freed, which will cause the thread releasing the interface to wait for the asynchronous call to complete. This is something that you might see while debugging, when exiting the method that created the IAsyncCall may take a mysterious amount of time.
OTL is in my opinion the most versatile of your three options, and I would use it without a second thought. It can do everything TThread and AsyncCalls can do, plus much more. It has a sound design, which is high-level enough both to make life for the user easy, and to let a port to a Unixy system (while keeping most of the interface intact) look at least possible, if not easy. In the last months it has also started to acquire some high-level constructs for parallel work, highly recommended.
OTL has a few dozen samples too, which is important to get started. AsyncCalls has nothing but a few lines in comments, but then it is easy enough to understand due to its limited functionality (it does only one thing, but it does it well). TThread has only one sample, which hasn't really changed in 14 years and is mostly an example of how not to do things.
Whichever of the options you choose, no library will eliminate the need to understand threading basics. Having read a good book on these is a prerequisite to any successful coding. Proper locking for example is a requirement with all of them.
There is another lesser known Delphi threading library, Misha Charrett's CSI Application Framework.
It's based around message passing rather than shared memory. The same message passing mechanism is used to communicate between threads running in the same process or in other processes so it's both a threading library and a distributed inter-process communication library.
There's a bit of a learning curve to get started but once you get going you don't have to worry about all the traditional threading issues such as deadlocks and synchronisation, the framework takes care of most of that for you.
Misha's been developing this for years and is still actively improving the framework and documentation all the time. He's always very responsive to support questions.
TThread is a simple class that encapsulates a Windows thread. You make a descendant class with an Execute method that contains the code this thread should execute, create the thread and set it to run and the code executes.
AsyncCalls and OmniThreadLibrary are both libraries that build a higher-level concept on top of threads. They're about tasks, discrete pieces of work that you need to have execute asynchronously. You start the library, it sets up a task pool, a group of special threads whose job is to wait around until you have work for them, and then you pass the library a function pointer (or method pointer or anonymous method) containing the code that needs to be executed, and it executes it in one of the task pool threads and handles a lot of the the low-level details for you.
I haven't used either library all that much, so I can't really give you a comparison between the two. Try them out and see what they can do, and which one feels better to you.
(sorry, I don't have enough points to comment so I'm putting this in as an answer rather than another vote for OTL)
I've used TThread, CSI and OmniThread (OTL). The two libraries both have non-trivial learning curves but are much more capable than TThread. My conclusion is that if you're going to do anything significant with threading you'll end up writing half of the library functionality anyway, so you might as well start with the working, debugged version someone else wrote. Both Misha and Gabr are better programmers than most of us, so odds are they've done a better job than we will.
I've looked at AsyncCalls but it didn't do enough of what I wanted. One thing it does have is a "Synchronize" function (missing from OTL) so if you're dependent on that you might go with AynscCalls purely for that. IMO using message passing is not hard enough to justify the nastiness of Synchronize, so buckle down and learn how to use messages.
Of the three I prefer OTL, largely because of the collection of examples but also because it's more self-contained. That's less of an issue if you're already using the JCL or you work in only one place, but I do a mix including contract work and selling clients on installing Misha's system is harder than the OTL, just because the OTL is ~20 files in one directory. That sounds silly, but it's important for many people.
With OTL the combination of searching the examples and source code for keywords, and asking questions in the forums works for me. I'm familiar with the traditional "offload CPU-intensive tasks" threading jobs, but right now I'm working on backgrounding a heap of database work which has much more "threads block waiting for DB" and less "CPU maxed out", and the OTL is working quite well for that. The main differences are that I can have 30+ threads running without the CPU maxing out, but stopping one is generally impossible.
I know this isn't the most advanced method :-) and maybe it has limitations too, but I just tried System.BeginThread and found it quite simple - probably because of the quality of the documentation I was referring to... http://www.delphibasics.co.uk/RTL.asp?Name=BeginThread (IMO Neil Moffatt could teach MSDN a thing or two)
That's the biggest factor I find in trying to learn new things, the quality of the documentation, not it's quantity. A couple of hours was all it took, then I was back to the real work rather than worrying about how to get the thread to do it's business.
EDIT actually Rob Kennedy does a great job explaining BeginThread here BeginThread Structure - Delphi
EDIT actually the way Rob Kennedy explains TThread in the same post, I think I'll change my code to use TThread tommorrow. Who knows what it will look like next week! (AsyncCalls maybe)
This is entirely theoretical at this point, but I've been trying to wrap my
head around this problem. Let's take a client for an example. There are
forkIOd threads for every connection, and one of them wants to quit the
entire program (ie. /exit). How would this information be propagated to
other threads?
This is not a condition, but I assume that the threads are reading from
their respective threads which are blocking. Since they're idling away
until something is written for them, they can't poll any kind of "done"
variable. So my first thought unless done is bunked.
I don't have a solution in mind for any program, so anyone giving solutions
for any language is appreciated, but the real question is how to do it in
Haskell.
The best way I know of is poison, which is implemented by the CHP library.
See the excellent explanation here: http://chplib.wordpress.com/2009/09/30/poison-concurrent-termination/
The above article incidentally goes through other solutions and explains why they're generally somewhat fragile.
Is there any documentation on cross thread communication in Delphi? How can I send message to the thread that doesn't have a window?
You can only send (Windows) messages to threads that implement a standard message loop, which will automatically be created once a window handle is realized.
It is however not necessary to use messages to communicate with a thread. Just let it wait on an event object (TEvent in VCL), and signal this event when you want the thread to perform a function.
But if you are new to multi-threading - don't go into all these details on your own, unless you want to for the learning effect. Just use the OmniThreadLibrary and be done with it. There's much good to be learned by digging into its internals, once you know how to use it.
Edit:
See also the answers to this question which is very similar.
Edit 2:
Regarding the comment asking "What does [OmniThreadLibrary] make easier, and at what cost?" I can only advise you to check it out for yourself - that is if you are using at least Delphi 2007. There are several samples to illustrate the concepts, but for a quick "real-life" example you could have a look at this blog post - you don't even need to install the library for that.
I do also agree that using a library for multi-threading does require a certain act of faith. OTOH making do with what the VCL provides is hardly an alternative. The sample code does still use the ill-conceived Synchronize() call. There is no support for things like thread-safe producer-consumer-queues, which are much more suited to multi-threaded programming. And if you do agree that you need a more solid fundament for your multi-threaded programs than the VCL provides - why reinvent that particular wheel?
As for the cost of using the library: You will have to time yourself whether it is fast enough for you. It does abstract the communication between threads in a good way IMHO, but every abstraction costs performance, obviously.
If you decide that it is not for you after all - write the code yourself. I did the same for Delphi 4, and I have been using that code for nearly 10 years now. And judging by the amount of bugs I found and corner cases I experienced in that time, I would definitely advise anybody new to multi-threading to not write their own library code for it. And if you really really want to, please take the rules in this posting to heart.
The question Delphi Multi-Threading Message Loop also contains a few examples of communication between threads
If you have a reference to the thread object, you can just call it direct, and have the procedure store information or update accordingly. Obviously you have to be careful to do things in a thread safe manner.
Alternatively, you could use a central control object through which the threads communicate when they aren't busy. I have an app where threads have particular purposes, and are allocated a thread-ID. Any thread can "post" a message with a message-ID and a string for parameters to another thread-ID and then get on with its work. The other thread the picks it up at its leisure, and acts accordingly.