As promised, I’m releasing OmniThreadLibrary with 64-bit support today!
Get it now: ZIP, SVN, UML diagrams (provided by Rich Shealer).
If you’ll be using it in production, wait until Tuesday as I won’t be fixing any bugs over the weekend and on the Monday there is a public holiday here in Slovenia.
OmniThreadLibrary 3.0 beta is available for download. Please test and report any problems.
Version 3.0 will be officially released on Friday.
For quite some time, thread pool in OmniThreadLibrary had a weird problem – if you scheduled more than 80 tasks in one go, FastMM would report memory leaks when application was terminated. It bothered me, of course, but I could never find the real reason behind the problem. And so I left the code “as is” and said to myself that nobody would encounter it in practice, anyway.
And then Žarko came and wrote about me on his blog :( In case you are living in a dark cave and didn’t hear of him – Žarko runs immensely popular Delphi site at About.com. His testing (and most of all his highly reproducible test case) gave me a new energy to pursue the problem.
The reason for the memory leak was a reference count leak in TOmniInterfaceDictionary, which is now fixed in the SVN. I also found some very tricky race conditions in TOmniTask.Execute and TOmniTask.Terminate and a cause for weird "A call to an OS function failed" error in DispatchEvent. All in all, I had two very productive bug-hunting nights. But that’s not why I started writing this article. I wanted to tell you a debugging story titled “How to find a missing Release.”
It is my pleasure to announce the availability of OmniThreadLibrary 3.0 beta. The main focus of this release is on the 64-bit support. Every part of OmniThreadLibrary is now compatible with the Windows 64-bit platform!
The current status of the code is “It works on my machine”. That is not pretty encouraging and I would really like to see some external testing. If you are using OTL, please get the fresh copy from the SVN and check if your applications are still working. 64-bit bugs are not a big problem right now – they will be squashed before any 64-bit OTL code goes into production – but I’d really like not to break existing code. Thanks!
Thread pool is working, other tests are passing nicely and it looks like you’ll be able to get your hands on the alpha version tomorrow.
Second milestone reached – dynamic lock-free queue works in 64 bits as does blocking collection. The latter is basis for most high-level threading abstractions in the OmniThreadLibrary so this is quite an important milestone.
Thread pool was not tested yet so the code is still in “look but don’t touch state”.
First milestone reached!
“Bounded” containers (fixed-size stack and queue) are now working fine both in 32- and 64- bits!
This is quite an important step because those containers are used to transfer data between OTL controllers and threads (i.e. they are used inside the Comm mechanism). They also contained quite some assembly code.
Great thanks to GJ who did all hard work to make x64 OTL possible!
Initial work has been committed on the x64 development branch: http://omnithreadlibrary.googlecode.com/svn/branches/x64
Current status is “Look but don’t use”. Many parts are still broken.
As you know if you follow my blog, OmniThreadLibrary now offers a simple way to do optimistic and pessimistic atomic initialization which works for interfaces, objects and (in the case of the pessimistic initialization), anything else. [In case you missed those articles - I also discussed a comparison of both methods and wrote a short post about the third approach to initialization.]
A typical usage of both types of initialization would be:
var sl: TStringList; ol: Locked<TObjectList>; Atomic<TStringList>.Initialize(sl, function: TStringList begin Result := TStringList.Create; end); ol.Initialize( function: TObjectList begin Result := TObjectList.Create; end);
As you can see, this is pretty long-winded. If you are initializing an interface, then you’ll usually have written a factory method already and the code would be much simpler (example below this paragraph) but in the case of objects this is not very typical.
Atomic<IGpIntegerList>.Initialize(list, TGpIntegerList.CreateInterface);
So I thought – both Atomic and Locked already know what entity type they wrap around so calling a constructor from inside Initialize would be trivial, eh? I could then write a simplified version
Atomic<TStringList>.Initialize(sl); ol.Initialize;
and use the longer version only when needed, for example to initialize interfaces or to call a non-default object constructor. What could possibly go wrong?
class function BusyWait<T>.Initialize(var storage: T; factory: TFactory): T; begin if storage = nil then begin if InterlockedCompareExchangePointer( PPointer(@storage)^, PPointer(@factory)^, nil) = nil then storage := factory() end; while PPointer(@storage)^ = PPointer(@factory)^ do Sleep(0); end;[This is not exactly the algorithm GJ proposed but my modified version, changed to work in a generic class.]
When you want to initialize a shared resource in a multithreaded application, you have two possibilities to choose from – optimistic and pessimistic. The difference between them is visible from the pseudocode.
var
Shared: T;
procedure OptimisticInitializer;
var
temp: T;
begin
if not assigned(Shared) then begin
temp := T.Create;
if not AtomicallyTestAndStore(Shared, nil, temp) then
temp.Free;
end;
end;
procedure PessimisticInitializer;
begin
if not assigned(Shared) then begin
Lock;
try
if not assigned(Shared) then
Shared := T.Create;
finally Unlock; end;
end;
end;
for i in Fibonacci(10) do Writeln(i);Of course you need a Fibonacci-implementing enumerator. I wrote one on 2007 and it uses the iterative approach. Read more in my old article Fun with enumerators, part 6 – generators.
This one was prepared for ITDevCon 2011 as an example of tricky (but pretty much useless) example of what can be done using anonymous methods.
