views:

980

answers:

7

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)

+7  A: 

Not a framework as such, but there's AsyncCalls. Its scope is different from OmniThreadLibrary, but it supports older versions of Delphi as well.

Mihai Limbășan
+4  A: 

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)

mjustin
Both are at least one abstraction level lower. Not what I would call Threading Frameworks.
mghie
I didn't know about the Indy thread safe data types. Very cool!
Mick
+2  A: 

Another one is TBMDThread set from Mitov Software

pani
A: 

Be wary of automatic conversions of string types. - To and from widestrings in particular.

Also be aware that many standard functions are not threadsafe. (For example, Format).

Arafangion
How is that about threading frameworks?
Smasher
Threading frameworks go hand-in-hand with data access methodologies, typically locking, but transational memory access and other methods are also available, so, sorry, I don't understand your question.
Arafangion
+11  A: 

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

Charles Faiga
+1. Connected with your second point is IMO that it focuses on executable work units (tasks) instead of threads. Threads (or thread pools) are just the vehicle to get things done. That's what makes this a real framework, not a simple facade for VCL threading.
mghie
On the minus side, it has lousy documentation. But I'll fix that - I promise. I will I will I will!
gabr
Well gbar is honest: the documentation must be improved, upvote nonetheless...
Remko
A: 

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

Cheers, Misha

Misha Charrett
I followed your link to check this out, but the list of required libraries turned me off immediately. You would have to provide a **lot** of advantages over OTL to make that acceptable. Could you add some more information about the threading framework itself?
mghie
+1  A: 

I don't seem to be able to edit my own answer, so this is in response to the comment above (or below, depending how the messages are ordered).

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)
Misha