I'm writing a Swift client to communicate with a server (written in C) on an embedded system. Its not iOS/OSX related as I'm using the recently released Ubuntu version.
Does Swift have any native support for concurrency? I'm aware that Apple discourages developers from using threads and encourages handing tasks over to dispatch queues via GCD. The issue is that GCD seems to be only on Darwin (and NSThread is a part of Cocoa).
For example, C++11 and Java have threads and concurrency as a part of their standard libraries. I understand that platform specific stuff like posix on unix could be used under some sort of C wrapper, but for me that really ruins the point of using Swift in the first place (clean, easy to understand code etc.).
2021 came and...
Starting with Swift 5.5, more options are available like async/await programming models and actors.
There is still no direct manipulation of threads, and this is (as of today) a design choice.
If you’ve written concurrent code before, you might be used to working with threads. The concurrency model in Swift is built on top of threads, but you don’t interact with them directly. An asynchronous function in Swift can give up the thread that it’s running on, which lets another asynchronous function run on that thread while the first function is blocked.
Original 2015 answer
Quoting from Swift's GitHub, there's a readme for "evolutions" :
Concurrency: Swift 3.0 relies entirely on platform concurrency primitives (libdispatch, Foundation, pthreads, etc.) for concurrency. Language support for concurrency is an often-requested and potentially high-value feature, but is too large to be in scope for Swift 3.0.
I guess this means no language-level "primitives" for threading are in the pipeline for the foreseeable future.
Related
Kotlin vs Node JS for REST Api's
I couldn't find any proper explanation regarding the differences b/w Kotlin and Node JS for REST APIs
Which is better in performance wise?
Let me set the context. Its Kotlin/JVM vs JS/Node.js. We cannot blindly say that this language is better. In general Kotlin is supposed to be faster since it compiled language compared to JS which is interpreted language.
Irrespective of the language used, we will discuss on the API architecture. Serving the APIs can be implemented in either blocking or non-blocking way (I am not going to explain about what it is). Traditionally before a few of years Java/Kotlin with Spring have been using the blocking architecture which delivered performance X. On a contrary, Node.js is based on non-blocking architecture which gave us better performance than the blocking architecture and architecture style is the only reason why Node.js performed better. Later Spring released a newer version of the framework to support non-blocking architecture. The non-blocking style is called as Reactive programming/Spring Webflux.
So now both of the languages support non-blocking architecture. In terms of raw language performance, Kotlin will be better since its compiled language. Also in theory interpreted languages are supposed to be slower. But we cannot say which is better without any testing.
Personally I am fan of Java/Spring because of OOPS and later at one point I started using TS/Node.js. TS eliminates most of the runtime issues with its type checking. But still we cannot compare it with the type system available in Java/Kotlin. As a language I feel Java/Kotlin is superior and one thing I like most in JavaScript is handling objects/JSON. Checkout "Kotlin for JavaScript" as well which lets you write in Kotlin and transpile to JS. Ignore this "Kotlin for JavaScript" feature, I am planning to try Kotlin/Spring in non-blocking architecture for my future projects. If you have usecases with WebSockets, I think Node.js will perform better and I am not sure If there are any libraries in Java/Kotlin since I havn't explored it.
One disadvantage in non-blocking style is that I need to pass the login context object to almost all the methods in the project. In blocking architecture we will add the login context information in thread local so that we can access it anywhere until the request is completed.
I am sure that I did not answer your question completely. But I hope that the information what I have give is useful.
Correct me If I am wrong in any of the aspects.
Are there any javascript libraries for MPI? I am new to MPI and am learning about intensive parallel processing. We have a supercomputer at school that we are using that only uses MPI and I was wondering if I could code my programs using Node.js instead of c++.
Thanks.
A quick search on NPM doesn't reveal anything interesting, so my guess is that it does not exist yet.
However, you can use native libraries with http://nodejs.org/api/addons.html.
You can also use node-ffi, which sometimes makes things even simpler.
I know this answer is coming too in April 2019... But for future use and people interested in this topic:
Option 1: You can use Node.js Cluster API (https://nodejs.org/api/cluster.html) to mimic or implement simple MPI functions e.g. send, receive, rank, etc.. and much more advanced functions depending on your programming prowess in Node.js.
Option 2: You can also use the following Node.js' MPI library, which implements some of MPI functionalities. The library is available in NPM registry:
mpi-node - https://www.npmjs.com/package/mpi-node
I recently created klyng, a message-passing distributed computing framework for Node.js influenced by MPI. You can consider it (for now) a small implementation of the MPI Standards in javascript.
There seems to be one now. It seems to be becoming a popular standard in most languages.
Here's one web site:
https://www.npmjs.com/package/mpi-node
We have a large c++ codebase that I'm porting onto Android. We had the foresight to abstract various platform-dependent features (threading, file access etc), so the process involves the gradual implementation of Android-appropriate code functions in the NDK
I was getting on reasonably well until I realised that semaphores (used in our core code) don't appear to have an implementation in the NDK.
I was wondering if it were possible under this (and possibly other) circumstances to implement the required functionlity (if it exists) in the SDK, e.g a 'Java' Semaphore and pass it down to the native code via the JNI interface for the native code to operate on it via appropriate callbacks.
Is there a reason why this might be inadviseable for synchronisation purposes?
Thanks
Have a bad news guys. Semaphore isn't implemented on android version of pthread google source
As for me flock(2) is an answer. But there is potential problem where you are trying to lock same file from different users.
Probably the worst consequence of using a Java-based implementation that you pass to your native code is that your semaphore operations will be very slow since they have to cross the JNI boundary.
Is there any reason why you can't use POSIX semaphores? See semaphore.h from the NDK's headers.
While multithreading is faster in some cases, sometimes we just want to spawn multiple worker processes to do work. This has the benefits of not crashing the main app if one of the worker crashes, and that the user doesn't need to worry a lot about inter-locking stuffs.
COM+'s Application Pooling seems like a good way to achieve this on Windows. The downside is that we need to write a COM+ wrapper for the worker process.
However, when I search for Application Pooling on Google, it seems like most of its usages are related to IIS. Don't other applications (such as scientific/graphics) find it useful to spawn multiple worker processes?
So there are several questions:
Why isn't COM+ more popular in areas other than IIS? If I write a non-IIS application and want to use process management on Windows, should I go with COM+ or are there better alternatives out there?
What would be the cross platform way to do it? Are there libraries out there that give me a "process pool" (worker processes will intelligently pick up work, can be managed, etc.)
I can't offer any answers to the COM aspect of your question, but it's worth noting there's another world (besides HPC MPI) where multi-processing (rather than the more common multi-threading approach) is apparently alive, well and thriving: Python.
Why ? Python's GIL ("global interpreter lock") cripples most attempts to multithread python code so badly that multiprocessing is the generally recommended approach to parallelising Python on SMP. The standard library includes process pools; there are various other options too.
Python certainly ought to satisfy any multi-platform requirement!
You might want to investigate how the apache web server manages process pools. From version 2.0 it runs natively on windows and one of the multi-processing models it supports are process pools. A part of apache is also APR (apache portable runtime), which handles platform-specific issues.
No one can answer why something is not popular because may be no body is looking for what you are looking for. After .NET came in picture, people shifted from COM to Managed Environment, before .NET, COM and ATL and relative other technologies were quite painful to implement and they would crash and were also quite difficult to debug.
That is the reason, managed environment came in existence.
However, .NET 4 onwards, parallel libraries give much more power to user for parallel programming and also you can spawn and control other proceeses.
For multiplatform, you can look for zvrba's answer.
Yes, other applications--especially science applications--find it useful to spawn multiple processes. Since few super-computers run Microsoft Windows, scientists generally avoid using anything that ties them to a Microsoft platform. Nothing related to COM will help scientists leverage their enormous existing code base written in Fortran.
People who choose to run IIS have generally already drunk the Microsoft Koolaid, so they have fewer inhibitions to tying themselves to Microsoft's proprietary platforms, which is why COM-specific terminology will get lots of hits related to IIS.
One of the open standards for doing what you want is the Message Passing Interface. Several implementations exist and some of them run on supercomputers using Fortran. Some of them run on cheaper computers using sexier languages.
See http://en.wikipedia.org/wiki/Message_Passing_Interface
There hasn't been a mob rushing through the doors of COM application pooling primarily because of two factors:
COM is a pain in the ass to deal with compared to just about anything else
Threading can be a headache, but it's a lot easier and more convenient to manage than inter-process communication
COM application pooling was essentially created for IIS. It has one very specific benefit over normal multithreading: the multiple processes are fully isolated from each other. This is important for data security and for app stability when dealing with third party plugins of questionable stability.
Scientific computing generally doesn't need strong data security isolation between operations, and I would venture to guess that scientific computing doesn't rely much on third party plugins of questionable stability. When doing big math operations, you're either using a sexy numerics library that had better be rock solid to be taken seriously, or you're using your own code, in which case crashes should be fixed and repeat offenders should be spanked.
Oh, and all crashes except stack overflow can be trapped and dealt with within a multithreaded app, especially if it's your own code.
In short, COM app pooling is overkill for just about anything other than IIS.
Google's webbrowser chrome is a multi-process architecture software. It is open source, so you can check out its code and see how to manage processes.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am looking for a Threading framework to use in my Delphi application.
Currently I am evaluating ‘OmniThreadLibrary’ - so far it looks good and does everything I need.
Is there any other ‘Threading framework’ for Delphi ?
(I am using D2006 & D2009)
As per Vegar Suggestion
Based on my few hours of evaluating OmniThreadLibrary
Here are some of the things I like about it
1) It is simple to use
2) It hides most of the details about multi threading
3) With a few lines of code you can set up multiple threads
4) It is easy to do inter process messages
5) It is still been actively developed
Not a framework as such, but there's AsyncCalls. Its scope is different from OmniThreadLibrary, but it supports older versions of Delphi as well.
Internet Direct (Indy) contains IdThread and thread safe data types in IdThreadSafe.pas:
* TIdThreadSafeInteger
* TIdThreadSafeBoolean
* TIdThreadSafeString
* TIdThreadSafeStringList
... and some more
The Jedi Code Library (JCL) also includes synchronization classes and functions (around ten classes)
I have been developing my own extensive threading framework, which is also integrated with a similarly architected communications framework, over the last 10 years. At this stage it can be used with Delphi 2005-2007, but will soon be available for Delphi 2009-2010. This application development framework can be used to build massively distributed systems as it is designed to enable any threads to run in any process and uses a simple thread-communications protocol that is the same whether the threads are in the same process, or in different processes on different machines.
As an additional feature I have this framework now running in C#/Visual Studio so a distributed system built using this framework can have a mix of Win32 and .NET applications, all using the same design methodology. The framework can be downloaded from http://www.adug.org.au/downloads/CSIFramework.html
The libraries that are used by my framework are not as extensive as it must have appeared from the site (I have just reworded that page, but it may take a day or so to be updated). Furthermore, all required files (apart from the database abstraction layer) are included with the framework, so no third-party libraries need to be installed to use the framework.
Beyond Delphi, the libraries used are:
Indy (included with Delphi, although I use the latest pre-unicode version)
JEDI JCL
Turbopower Abbrevia
an XML tidy library (optional)
a database abstraction library (optional)
I have modified some peripheral Delphi units 1) to fix a memory leak in the open XML implementation in Delphi 2006 (subsequently fixed in later Delphi versions), 2) to integrate the service application with my logging framework, and 3) to integrate the stand-alone SOAP server with Indy 10 (not Indy 9 as included with Delphi 2006).
In reality, my framework is much, much more than just a threading framework, although the threading framework is part of it. The threading framework is built by implementing all threads as threaded queues. The "messages" passed between the threaded queues are actually data packaged in a generic typed object, which allows me to pass absolutely any data structured in any way between threads. I can pass messages between threads either asynchronously, by adding a message, or synchronously, by adding a message and receiving a message in response. The threads themselves subscribe to other threads to receive messages, so there is no coupling between the threads at design time.
This framework has been extended to include communications servers and clients, and the main GUI thread, to have exactly the same messaging interface as the threaded queues, so sending a message to a remote process, or passing it onto the GUI, uses the same syntax as that used between threads. The framework has been designed in a way that there is no requirement to know anything at all about multi-threaded development to build a distributed system deployed across multiple processes and multiple threads.
There is a lot more to the framework than this and I have put in more than 2 years worth of effort to develop this over the last 10 years. It has been successfully deployed in a multi-tier alarm monitoring system (utilising over 20 different classes of thread across three applications), and I am currently building a distributed system in Visual Studio 2008 using this framework.
In short, if all you want is a simple threading framework, then this is probably overkill. However, if you want to develop a complex multi-threaded system which might span multiple applications then the learning curve may be worth it.
PS Another few points:
Thread startup and shutdown is all handled by the framework (no need to write any code to do this)
The threads that comprise the application (number and configuration) are all defined in an an XML configuration file, not in the code itself (no need to write any code to include them in the application)
If you use the database abstraction component then multi-threaded database access is automatically available (no extra code required)
I am currently working on adding thread pooling, which will allow any threaded queue to have a specified number of instantiated threads (again, no need to write any code to do this)
There is a simple developer's guide that you can download from the web page which is also included in the framework download that gives an overview of the framework from a developer's perspective
The framework itself is under very active development, and with the next release of Delphi I hope to have a version running on Win32 (under Delphi), a .NET version (C#/Visual Studio), and a Linux version (using the new Deplhi cross-platform compiler)