What thread synchronization mechanisms are available in VB6?
None natively, If you do threading in VB6, you'll iether have to make heavy use of the threading Windows API functions (for good info on this see Dan Applemans books or the Matthew Curland book "Power Techniques for Everyday Programmers")
You can also do threading via COM via timers and COM apartment threading, but that also requires quite a bit of framework code, and even then, you still have to code the synch functionality yourself.
There are no built-in thread synchronization mechanisms - use Win32 API calls to access built-in windows synchronization mechanisms. See this example
Related
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.
Just to confirm if multithreading is supported in iPad and iPhone. I need to write an application that calls a web service on a background thread while user can still interact with the UI.
Yes, it has threads.
Also, you don't need to spawn your own threads for most tasks. A lot of the Apple Frameworks (Cocoa Touch Foundation frameworks) have built-in code that will do this for you.
Also, if you're consuming data from a Web API (HTTP Request), I highly recommend you take a look at ASIHTTPRequest, which is built on top of NSOperation (an operation class that easily handles background processing).
Finally, if you need help on program design/flow using the Model-View-Controller pattern, I've written a blog entry describing how to consume Web API data and present it to the end-user in a table format.
iOS has always supported multi-threading, just as Mac OS X did before it. Here's Apple's excellent overview documentation on the subject:
Concurrency Programming Guide
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.
I'm writing a .NET 4.0 library that should be efficient and simple to use.
The library is used by referencing it and using its different classes.
Should I use .NET 4.0 Tasks tot make things more efficient internally? I fear that it might make the usage of the library more complex and limited since the users might want to decide for themselves when and where to use tasks and threads.
If your answer depends on the kind of library, here is more information:
The library is Pcap.Net, which is a wrapper for WinPcap and includes a packet interpretation framework.
It only is an issue when the user can 'see' the threading, ie you give out access to data that could be accessed (by you) on another Thread. Probably not a good idea.
But when the parallel processing stays completely inside your application then there is very little chance your users would object.
Should? Dunno. How about giving people an option by providing extension methods that use tasks against the library and push that out in a separate DLL? If you want to use tasks, reference the extension library and go crazy. Otherwise, stick with the core dll.
I believe there are many projects that follow this pattern with Linq. They provide their core library and a separate .Linq.DLL which has extension methods...
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)