ThreadSafe Lock Manager: [1] Design

Few weeks ago I ran into a problem. I needed a thread-synchronizing code that would work similarly to a critical section, but would allow me to lock “anything”. If I could limit myself to objects, I could live with TMonitor.Enter/Exit, but I specifically wanted to limit access to some string keys. [In a way, my problem was similar to a problem of locking access to specific items in a string-keyed dictionary. Details differed, though.]

I was thinking about the problem and it turned out not to be a simple one. Yes, I could solve it by introducing a string-keyed dictionary of critical sections but that would be a little bit too limiting for my taste. I had some other requirements in mind which further complicated the implementation.

TL;DR – This lock manager is implemented in the OmniThreadLibrary as IOmniLockManager<K>/TOmniLockManager<K> in the OtlSync unit since revision 1268.

Using Generics to Manipulate Enumerated Types

I’d like to present a short class written by my colleague at work. Why? Because I just love how it uses the generics syntax to simplify some operations on enumerated types.

Like me, he hated the hoops one must jump through to convert an instance of an enumerated type to a string, to check if an integer value that was read from some storage contains a valid integer representation of some enumerated value and to enumerate (no pun intended) over such a type. Unlike me, he did something about that and wrote a Spring-inspired Range<T>.

Numbers I Should Keep In Mind

Name	Nanoseconds
L1 cache reference	0.5
Branch mispredict	5.0
L2 cache reference	7.0
Mutex lock/unlock	100.0
Main memory reference	100.0
Compress 1K bytes with Zippy	10,000.0
Send 2K bytes over 1 Gbps network	20,000.0
Read 1 MB sequentially from memory	250,000.0
Round trip within same datacenter	500,000.0
Rusty disk seek	10,000,000.0
Read 1 MB sequentially from network	10,000,000.0
Read 1 MB sequentially from disk	30,000,000.0
Send packet from CA->Netherlands->CA	150,000,000.0

From always excellent kellabyte.

Embarcadero Academy: The Power of XE3

Next Wednesday (March 13^th) we have organized a presentation for all users that are afraid to upgrade and are staying (for example) with Delphi 7. In “The Power of XE3” session I’ll go through all^* new features added to the Delphi and C++ Builder since Delphi 7 days. We’ll discuss language changes, platform changes, framework changes, additions to the VCL, RTL, database layer …

Register here.

---

^* As much as humanly possible. There are simply too many to cover them all.

Developer Wanted

The following text is a job offer for a Slovenian developer and is therefore written in Slovenian language.

Iščemo Delphi razvijalca za izpeljavo večmesečnega projekta. Zahteve: zna (ali se je pripravljen naučiti) osnovega dela z zbirnikom. Delovno mesto je v Ljubljani. Delo na domu ni možno.

Projekt je dvodelen, prva faza vsebuje predelavo aplikacij na MS Ribbon, druga pa predelavo taistih aplikacij, da se bodo prevedle za Win64.

Ob uspešni izvedbi projekta obstaja tudi možnost zaposlitve za nedoločen čas.

Prijave (s CV) in dodatna vprašanja pošljite na sandra.support@fab-online.com, v subject pa vpišite "razpis Delphi".

Če vas zanima, s čim se ukvarjamo, si oglejte www.fab-online.com.

When Does “Execute on Destroy” Fail

Yesterday I wrote a post about executing some code automatically when a method ends. Today I’ll show you why this approach must be used with care.

OmniThreadLibrary on Google+

OmniThreadLibrary now has its own Google+ community so you are welcome to visit it and ask questions, report bugs, discuss possible OmniThreadLibrary improvements and so on …

Running “Any” Code When a Method Ends

Just like (some) other programmers, I like to abuse the fact that the Delphi compiler only destroys local interfaces when a method ends. If you don’t know what I’m talking about, check out the latest Nick’s post in the Fun Code of the Week series.

As an example, Nick put together a function which changes application cursor and at the end of the method reverts it back to the previous state.

procedure test;
begin
  AutoCursor(crHourGlass);
  // some long operation
  // cursor is automatically reverted when ‘test’ exits
end;

My approach to this pattern is usually slightly different. I like to mark the scope of the local interface with a with statement.

Accessing Input Queue of a Pipeline Stage

On the today’s “Multithreading” workshop, a request popped up – a potential OmniThreadLibrary user asked how to access an input queue of a specific pipeline stage. As this was the second time this request was presented, I decided to implement this feature. It turned out that all available information was already present and I just had to expose it.

Embarcadero Academy: Multithreaded Programming 1.1

The “Embarcadero Academy 2012” series of Delphi-related workshops was very well accepted in Slovenia so we (Embarcadero, Slovenian distributer Marand and me) have extended it into year 2013. The first workshop will be – due to a popular demand – revisited extended workshop on multithreaded programming. I’ll be extending the topics covered in the first workshop with many practical examples.

The date is slightly awkward – February 21st, the same date when Embarcadero will present the “Delphi for iOS” programming tool. Luckily, we’ll finish around 01:00PM which will give everyone enough time to return to the office and watch the webinar which starts at 03:00PM. (We apologize for this – we selected the date when Embarcadero’s webinar was still announced for the 14th but then Emb. moved the date a week ahead.)

As always, workshop will be lead in Slovenian language. Register here!

The OTL Book–Russian Edition

Just a quick notice to my readers – the Russian translation of Parallel Programming with OmniThreadLibrary has been updated and now contains all the material from the English edition.

Big thanks go to Alex Egorov for his hard work!

Žarko is back!

Add this link to your RSS reader: http://zarko-gajic.iz.hr/feed/

Sending Event Handlers Across Thread Boundary

Recently, I ran into an interesting problem. I was doing some high-bandwidth, low-latency data processing where a background task received the data, dispatched it to a central hub which then forwarded data to the appropriate data processing & transmitting thread. Data absolutely had to travel through the main thread (the reasons for that are quite convoluted and not important for the story) which bothered me from a performance viewpoint. This could introduce some unwanted overhead as I can only send data to the main thread via Windows messages.

The simplest (given the current codebase) way to solve the problem was to introduce an asynchronous event handler. The main thread implements an event handler called for each received data block and passes this event handler to the receiver thread, which calls the event handler from its own context. As a result, the code that logically belongs to the main thread is executed from the worker thread and there is (almost) no delayed introduced. (The ‘almost’ part coming from the fact that I had to use some locking to synchronize operations inside the main thread.)

During the implementation phase, I found out that it’s quite difficult to send an event handler over the OmniThreadLibrary communication channel. The solution was non-trivial and required quite some ugly hacks so I’m posting it here for future reference.

DataSnap Speed & Stability, Part 2

As the Roberto’s blog is still not listed on the DelphiFeeds, I’d like to bring your attention to his second article about DataSnap: DataSnap analysis based on Speed & Stability tests – Part 2.

Parallel Programming with OmniThreadLibrary: Synchronization

The “OTL book” has just been extended with a chapter on synchronization (22 pages). Basic understanding of synchronization issues and critical section usage is required as this chapter only deals with OmniThreadLibrary-specific support for locking.

OmniThreadLibrary ile Paralel Programlama*

Due to a strong language barrier we don’t hear from Turkish programmers much even though the programming (and Delphi) community in this big country is quite strong. That’s why I was pleasantly surprised when I received a proposal from that country to translate the OmniThreadLibrary book. We quickly set up a workflow (as the OTL book is still being written this is not a trivial task) and the book is now being translated.

Although I didn’t see more than a few translated paragraphs yet, I have great hopes that the initial Turkish release will join the ever growing family of the OTL books (English, Russian, Spanish) early next year. Until then, you can express the interest in the book here.

Great thanks go to Tugrul Helvaci for initiating the project and to Ramazan Gülbahar for translating the book!

* Parallel Programming with OmniThreadLibrary

DataSnap Speed & Stability

As the Roberto’s blog is not yet included in the DelphiFeeds concetrator, I’d like to bring to your attention his very interesting post: DataSnap analysis based on Speed & Stability tests.

Embarcadero Academy: Live Bindings

On Thursday, 29th I’ll be leading a workshop about LiveBindings and Visual LiveBindings in Ljubljana. The workshop will cover both XE2 and XE3 and will also cover differences between the VCL and FireMonkey implementation.

Predavanje bo v slovenskem jeziku. Prijavite se tu.

FireMonkey2 in Ljubljana

Last week I spoke at FireMonkey² workshop in Ljubljana. Attendance was low (compared to other “Embarcadero Academy” sessions) but very attentive and interested in the FireMonkey development.

Next session will be dedicated to LiveBinding (visual and nonvisual – both XE2 and XE3 will be covered) and is planned for 29. November. I’ll put a notice on my blog when a registration page is up.

OTL Repo Stable Again

Christian has finished the housekeeping tasks (days ago but I was busy and forgot to put a notice on the blog, sorry), so the repository is stable again.

Changes, with his own words:

• introduced lib path (now all lowercase) to receive all DCU files separated by compiler, platform and configuration. The tests compile really quick now, without "polluting" the source directory with .dcu files
• changed fastmm4 to fastmm, which is now an svn:external
• added main icon for all tests (linked via MainIcon.rc resource script)
• this still might cause linking issues on Delphi 2007, if compiled for the first time, but I will investigate this in the next days.
• removed unused files and directories from the svn repository