Why some Linux devs still use spinlocks.

There is An interesting article, on another BB, which explains what some of the effects are, of spinlocks under Linux. But, given that at least under Linux, spinlocks are regarded as ‘bad code’ and constitute ‘a busy-wait loop’, I think that that posting does not explain the subject very well of why, in certain cases, they are still used.

A similar approach to acquiring an exclusive lock – that can exist as an abstract object, which does not really need to be linked to the resource that it’s designed to protect – could be programmed by a novice programmer, if there were not already a standard implementation somewhere. That other approach could read:


from time import sleep
import inspect
import thread

def acquire( obj ):
    assert inspect.isclass(obj)
    myID = thread.get_ident()
    if obj.owner is None:
        # Replace .owner with a unique attribute name.
        # In C, .owner needs to be declared volatile.
        # Compiler: Don't optimize out any reads.
        obj.owner = myID
    while obj.owner != myID:
        if obj.owner == 0:
            obj.owner = myID

def release( obj ):
    assert inspect.isclass(obj)
    if obj.owner is None:
        # In C, .owner needs to be declared volatile.
        obj.owner = 0
    if obj.owner == thread.get_ident():
        obj.owner = 0


(Code updated 2/26/2020, 8h50…

I should add that, in the example above, Lines 8-12 will just happen to work under Python, because multi-threading under Python is in fact single-threaded, and governed by a Global Interpreter Lock. The semantics that take place between Lines 12 and 13 would break in the intended case, where this would just be pseudo-code, and where several clock cycles elapse, so that the ‘Truth’ which Line 13 tests may not last, just because another thread would have added a corresponding attribute on Line 12. OTOH, adding another sleep() statement is unnecessary, as those semantics are not available, outside Python.

In the same vein, if the above code is ported to C, then what matters is the fact that in the current thread, several clock-cycles elapse between Lines 14 and 15. Within those clock cycles, other threads could also read that obj.owner == 0, and assign themselves. Therefore, the only sleep() instruction is dual-purpose. Its duration might exceed the amount of time the cache was slowed down to, to execute multiple assignments to the same memory location. After that, one out of possibly several threads would have been the last, to assign themselves. And then, that thread would also be the one that breaks out of the loop.

However, there is more that could happen between Lines 14 and 15 above, than cache-inefficiency. An O/S scheduler could cause a context-switch, and the current thread could be out of action for some time. If that amount of time exceeds 20 milliseconds, then the current thread would assign itself afterwards, even though another thread has already passed the retest of Line 13, and assumes that it owns the Mutex. Therefore, better suggested pseudo-code is offered at the end of this posting…



This pseudo-code has another weakness. It assumes that every time the resource is not free, the program can afford to wait for more than 20 milliseconds, before re-attempting to acquire it. The problem can crop up, that the current process or thread must acquire the resource, within microseconds, or even within nanoseconds, after it has become free. And for such a short period of time, there is no way that the O/S can reschedule the current CPU core, to perform any useful amount of work on another process or thread. Therefore, in such cases, a busy-wait loop becomes The Alternative.

I suppose that another reason, for which some people have used spinlocks, is just due to bad code design.


Note: The subject has long been debated, of what the timer interrupt frequency should be. According to kernel v2.4 or earlier, it was 100Hz. According to kernel v2.6 and later, it has been 1000Hz. Therefore, in principle, an interval of 2 milliseconds could be inserted above (in case the resource had not become free). However, I don’t really think that doing so would change the nature of the problem.

Explanation: One of the (higher-priority, hardware) interrupt requests consists of nothing but a steady pulse-train, from a programmable oscillator. Even though the kernel can set its frequency over a wide range, this frequency is known not to be terribly accurate. Therefore, assuming that the machine has the software installed, that provides ‘strict kernel marshalling’, every time this interrupt fires, the system time is advanced by a floating-point number, that is also adjusted over a period of hours and days, so that the system time keeps in-sync with an external time reference. Under Debian Linux, the package which installs that is named ‘ntp’.


There exist a few other tricks to understand, about how, in practice, to force an Operating System which is not an RTOS, to behave like a Real-Time O/S. I’ve known a person who understood computers on a theoretical basis, and who had studied Real-Time Operating Systems. That’s a complicated subject. But, given the reality that his operating system was not a Real-Time O/S, he was somewhat stumped by why then, it was able to play a video-clip at 24 FPS…

(Updated on 3/12/2020, 13h20 …)

Continue reading Why some Linux devs still use spinlocks.

Print Friendly, PDF & Email

An interesting piece of trivia, about the industrial production of Hydrogen Chloride.

Hydrogen chloride, or, HCl, is generally agreed to be the simplest acid. But this does not automatically imply that HCl is also the cheapest acid. Why? One way in which HCl can be produced, is by allowing equal volumes of hydrogen gas and chlorine gas to combine:


Cl2 + H2 -> 2HCl


The problem with this reaction is the known fact, that it will generally take place explosively. Unlike the equivalent reaction for oxygen:


O2 + 2H2 -> 2H2O


Which can either take place as an explosion, or in a controlled way, the reaction that produces HCl directly, will take place in an uncontrolled way. What this does is to complicate how HCl is produced industrially. One process that can be used is, that concentrated sulphuric acid, which is, BTW, the cheapest available acid, can be made to react with either NaCl or CaCl2 in their solid form. And usually, CaCl2 is chosen as a starting material, from which to produce HCl, because, choosing this salt produces not one but two useful products:


H2SO4 (l) + CaCl2 (s) -> 2HCl (g) + CaSO4 (s)


That additional reaction product, CaSO4, is also referred to as “Gypsum” when hydrated, or as “Plaster Of Paris” when dry, and is a popular construction material. The reaction written above is actually the main way in which drywall is manufactured, with HCl being given off as a byproduct. Yet, instead of using CaCl2, it will work equally well to use NaCl:


H2SO4 (l) + 2NaCl (s) -> 2HCl (g) + Na2SO4


The reason why this second reaction is less-favoured, is the mere fact that Na2S04 is less of a useful product commercially. It’s also referred to as “Glauber Salt”.

But, regardless of which reaction has been chosen as a method to mass-produce HCl, doing so consumes sulphuric acid in equivalent quantities, and also produces either sulphate as a byproduct.



Print Friendly, PDF & Email

Will the Water-Gas Shift Reaction become a suitable means to fuel a fleet of Cars?

More than a century ago, there was a famous chemical reaction that could supply (combustible) fuel gas to cities, which was based on first turning coal into coke, and then passing steam over white-hot coke:


C(s) + H2O -> CO + H2


The gas mixture that resulted, of carbon monoxide and hydrogen gas, was both a source of fascination before the year 1900, and a reason why some city blocks ended up blowing themselves up, over the first Historic gas leaks.

What some people may not know, is that this chemical reaction was already accompanied by another reaction:


CO + H2O -> CO2 + H2


That coincidentally resulted in the gas-mixture containing a higher amount of H2 than it would contain CO, just because there was already steam present, when the water-gas was made. This second reaction is called the Water-Gas Shift Reaction.

There is one Historical context in which this reaction was always useful (as the cited article already points out). There have always been industrial consumers of hydrogen, who could not afford hydrogen produced by hydrolysis, but who could afford hydrogen that is partially contaminated with carbon monoxide. BTW, the CO2 can be removed from the gas mixture, by passing it over quicklime, producing some form of calcium carbonate. The only problem with using quicklime in the modern era is the fact that quicklime itself is produced primarily, by heating calcium carbonate, thereby releasing the equivalent amount of CO2 in advance… (:1)

But there is a context in which this reaction is almost useless. It uses a large supply of coal as its energy source, and also produces CO2 as a byproduct, the latter of which needs to be controlled, if a population of cars is to be fuelled with hydrogen.

I suppose, though, that some countries could be so desperate for an alternative source of energy, or so determined, that they’d consider trapping all the CO2 thus produced, before selling hydrogen to fuel-cell-powered -car owners. Those would probably be countries that also have a lot of coal as a resource. Those countries might also need to refine their fuel-cell technology, into fuel-cells which won’t become poisoned by the carbon monoxide still present in the hydrogen, which quicklime would not trap.

I tend to think of this reaction as a trip down memory lane.



Carbon monoxide reacts with methanol to form acetic acid, which can in turn be trapped by quicklime, just as carbon dioxide once was. In this case, the precipitate will be calcium acetate. Therefore, special fuel cells might not be needed.


(Update 2/18/2020, 18h05 : )

Continue reading Will the Water-Gas Shift Reaction become a suitable means to fuel a fleet of Cars?

Print Friendly, PDF & Email

What the difference is, between a Native and a Scanned PDF File.

As the subject line suggests, this posting will just define the subject of Native versus Scanned PDF Files.

I have encountered people who simply regard PDF Files as a convenient way to scan a stack of images – from paper – and to store those images. The resulting Scanned PDF Files do have advantages over certain other image formats, such that:

  • They can be password-protected, locked, ‘DRM’ed, etc.,
  • They keep track of a document consisting of more than one actual image, aka page.

But their main disadvantage is, that because they were scanned, they are also rasterized, which means that they have a fixed resolution in pixels. (‘Rasterized’ images are also referred to as ‘Pixel-Maps’ or ‘Bit-Maps’.) I supppose that if a paper document is being scanned, this is not a big deal, because the original document had a limit in its physical level of detail. (:1) But as an alternative, Native PDF Files also exist.

In order to understand what those are, the reader needs to be aware that a form of graphics exists in general, which is an alternative to pixel-based graphics, and that is called ‘Vector-Based Graphics’. What this form of graphics entails is, that there exists a Mathematical definition of a curve, which is often also referred to as a ‘Path’, the parameters of which can be changed from one path to the next. Those parameters need to state in floating-point numbers, where the endpoints of the path are, and, preferably, define what the derivative of the curve is at both endpoints. The most standard type of Mathematical function that does this is a Cubic Spline, but that is by no means the only function available.

A vector-based image consists of a collection of paths, each of which has a different set of these numerical parameters, even in cases where the function is always the same. Also, there often needs to be a stored detail, of how to render such paths, such as to fill in the area inside a closed path with a fill colour, etc..

Continue reading What the difference is, between a Native and a Scanned PDF File.

Print Friendly, PDF & Email