2

I'm looking for some threading framework to avoid writing it from scratches. Especially the tasks queuing and synchronization are what I need. I know OmniThreadLibrary which is great but is not compatible with D7. Any recommendations?

migajek
  • 8,524
  • 15
  • 77
  • 116
  • 2
    Queuing: `PostMessage`, `QueueUserWorkItem`. Synchronization: `Synchronize`, `WaitForSingleObject`. What more are you looking for from a "framework" that the OS and the RTL don't already provide? – Rob Kennedy Aug 28 '10 at 19:30
  • 5
    Rob, have a look at OmniThreadLibrary and the way it simplifies the threading :) – migajek Aug 28 '10 at 19:47
  • @migajek: Well, personally I tend to find low-level stuff easier to understand. The principles are simple. – Andreas Rejbrand Aug 28 '10 at 20:05
  • Indeed, the principles are simple, but I'd like to avoid reinventing the wheel (if there's any wheel available for D7 ;) ). – migajek Aug 28 '10 at 20:46
  • 1
    Can you not simply explain what you expect, instead of just pointing to an external package? Not all conclusions we might derive from inspecting Omnithreadlibrary might be equally important to you. – Marco van de Voort Aug 29 '10 at 13:15
  • as mentioned in the question itself, I'm looking for tasks queuing and a simpler (than using TThread) communication between tasks – migajek Aug 29 '10 at 15:46

3 Answers3

6

So you want to stay with Delphi 7, and you want a good thread library, but don't want to write it from scratch.

One day you will upgrade, I'm sure. So why go for a poor threading library that you'll need to change when you do.

My recommendation would be to take OmniThreadLibrary, and try to port it to work with Delphi 7. Then you'll have an upgrade path.

Otherwise, try one of the recommendations in: How Do I Choose Between the Various Ways to do Threading in Delphi?

Community
  • 1
  • 1
lkessler
  • 19,819
  • 36
  • 132
  • 203
  • The decision to stay with D7 or not is not up to me, unfortunately :( Otherwise I'd have upgraded to Unicode, generics-enabled version like D2010 :) Anyway thanks for the link, I must have missed it for unknown reason. – migajek Aug 28 '10 at 19:49
3

A threading framework could possibly save you months of work in the long run, so depending on how important it is for you to have one, maybe you can use this as a reason to upgrade. And anyone who suggests that TThread and other Windows synchronisation primitives are all you need obviously has not written much threaded code. I estimate that I have spent at least 3-6 months just to develop my own threading framework to make things easier, and it has easily "paid" for itself.

Misha
  • 1,816
  • 1
  • 13
  • 16
  • 3
    "And anyone who suggests that TThread and other Windows synchronisation primitives are all you need obviously has not written much threaded code." True, that's like asking why the VCL is needed when everything can easily be done using WIN32 API calls. – mghie Aug 29 '10 at 09:25
  • 1
    The question is not only if windows base apis are sufficient, the question is also if you can see a thread framework separately from the application framework for the class of apps you target. I have some doubts about that. – Marco van de Voort Aug 29 '10 at 13:19
  • 1
    IMHO, the threading framework should be an integral part of the application framework. I target service-type applications/systems which are almost by defintion multi-threaded/distributed systems, so my threading framework and my communications framework are tightly integrated together such that passing messages between threads is identical to passing messages between applications. – Misha Aug 30 '10 at 01:00
2

I'm not trolling when I say this, but how about TThread? Although not a framework, it certainly makes working with Windows threading far less painful. Seriously, it is very well done.

Here are some links to get you started:

Mick
  • 13,248
  • 9
  • 69
  • 119