The unintended consequence of not paying sick pay

By , March 6, 2020 4:49 pm

Setting the scene

I wrote this several years ago but it never became published. Reading it now it still seems to be valid. Even more so with coronavirus in the news.

Odds are that if you are reading this and you an IT professional this situation doesn’t apply to you. You are either employed in a full time permanent position (you receive sick pay) or you are a contractor (you provide your own sick pay – it’s a risk you take). This article is the result of a discussion with a friend. We are both based in the UK. In your country the legal aspects may be different but the principle remains.

However if you are a part time employee you may not be paid sick pay. I found this out when chatting with a friend of mine about one of their part time jobs (they have several, one main one to provide an income backbone and two others to ring the changes so they don’t do one type of work all the time).

I know this person really well. Conscientious, hard working, honest, caring, won’t accept jobs they can’t do well, etc. The type of person you want working for you. A string of events have happened to them recently that make them doubt their current main employer. First the employer won’t delegate and gets over stressed as a result. This then leads to the employer bad mouthing the staff to other people (which it turns out have been friends of some of the staff and in one case a customer – ooops!). This gets back to the staff and is seriously demoralising, especially when it’s unjustified.

Then recently my friend was ill for about a week. When they received their pay their pay they found out that they had not been paid for the days they took sick. You can imagine how this made them feel – not very valued by their employer. This has caused a lot of upset (and financial harm) to this person.

This raises some interesting questions.


  1. What do you gain/lose by paying sick pay?

  2. What do you gain/lose by not paying sick pay?

I’ve posed the questions in this way because this is surely the reasoning behind choosing not to pay sick pay. That paying it is a cost to be avoided and not paying it saves you money. Let us examine this:

What do you gain/lose by paying sick pay?

There is undoubtedly a risk that some of the people you employ are not going to be as honest as some others. Some put the hours in they are required to do and go home. Some do that and also do more and also do personal development. And some put the time in but take every opportunity to shirk off their work, be lazy and take sick days even when they are not sick.

It’s an unfortunate fact that some people will game the system to their advantage. If they know they’ll get paid for being ‘ill’ while they are really at the local cinema watching the latest flick on the first day of opening then they think that is a risk worth taking and they "pull a sicky"

But on the flip what you gain is loyalty from those staff that don’t fall into that group. They value the fact that you will look after them when they are ill. These people rarely abuse the sick day provision.

What do you gain/lose by not paying sick pay?

So there are pros and cons to paying sick pay. All reasonably obvious. But what about the consequences of not paying sick pay?

Let’s start with the obvious consequence: By not paying sick pay you save money not only by not paying for illegitimate sick day claims, but you also save money when hard working staff are ill too. Ca-Ching! Well, not really as you’ve just demonstrated to the hard working staff that you don’t value them. Pretty stupid move.

Any not so obvious consequences? Yes. If you are not going to be paid when you are sick, how is that any different to unpaid leave? Apart from the chances of dismissal if caught being dishonest, it’s the same. By not paying sick pay you remove any incentive to be honest about why you were not at work (were you ill or you just couldn’t be bothered or you thought tarring and feathering the local tramp was a better idea?).

"I fancy doing some decorating today? I’ll pull a sicky. I won’t get paid, but I will get this annoying job done. Which is more important to me today? My life is, Decorating it is then." And to hell with the business today. Instant holiday. No permission asked.

This one could leave some businesses in the lurch when they find out with no notice that someone isn’t coming in and the only reason is "I’m sick" (but what they don’t know is this person doesn’t care because they know they are not valued).

A lot of businesses employ part time staff. Many of them are businesses that start early in the morning and close late at night, resulting in a day longer than the typical 7.5 or 8 hours. The last thing these businesses need is to find out at 2pm as the second shift starts that a key team player isn’t coming in today. And by not paying sick pay they increase the likelihood of such a situation.

Working ill

The other unintended consequence of not paying sick pay is that people that are ill and should not attend work, may well choose to attend work because they need the money more than they need to stay in bed recovering. This is especially true of people on zero hours contracts and low pay contracts.

Coronavirus is in the news these days, and to stem this pandemic we really need ill people to do the right thing. But the right thing for society is in competition with the right thing for an individual on a low income who probably has negligible savings. They’re going to come to work with their illness as the short term gain for them (pay) outweighs the long term harm to others (some people may get ill). Humans discount future events, so that harm is in the distance and also not to them, as they’re already ill.

This latter scenario is seriously reduced as an outcome if people are paid enough to be able to take time off work when they are ill.

My friend – their choice

I’m not sure what they are going to do. What is clear though that having realised this unintended consequence and how their employer feels about them (despite customer comments to the contrary) their loyalty to the business has evaporated. I wouldn’t be at all surprised to find some unpaid "sick leave" happens to allow my friend to do various things they need to do in their personal life at the expense of the business they would otherwise be working for.

I guess some people are going to read this and think WTF? But the point is this consequence only happens when you have good conscientious staff and then you don’t value them. If they were paid sick pay they wouldn’t feel unvalued or even think of pulling a sicky, let alone an unpaid sicky (which is in this situation the same, but more wilful).

The really sad thing? My friend likes to do a good job. Wants to work where a good job and good attitude is valued. But it seems that for the types of work they do such employers are rare beasts (not like the IT world where to keep staff you have to be a good employer).

I’m not really sure if my words have done justice to what I’m trying to explain here.

Detecting Abandoned Critical Sections

By , March 6, 2020 4:24 pm

Multithreading is a powerful way to improve the processing throughput and responsiveness of your software. We use it to great effect at Software Verify. In order to manage multithreading successfully it’s necessary to use some form of synchronization between each thread that wishes to read/write data. Deadlocks can result. The main cause of deadlocks is two or more locks (critical section being an example) accessed in different orders on each thread. This has been the subject of much writing, so for now I won’t repeat that topic here.

There is another cause of deadlock which is less well known. The abandoned critical section.

In this article I’m going to describe how to detect abandoned critical sections. But first I need to describe them to you and explain how abandoned critical sections get created.

What is an Abandoned Critical Section?

An abandoned critical section is a critical section that has been locked but then the thread that owns the lock ends without unlocking the critical section. This creates a critical section that cannot be unlocked, and is thus permanently locked. If any other thread attempts to enter the critical section it will wait forever, in a deadlock caused by an infinite wait.

How does this happen?

There are several ways that a critical section can become abandoned.

  • Incorrect code.
  • Incorrect exception handling.
  • Terminate Thread.

Incorrect code

This is where the thread code enters a critical section to do some work and forgets to unlock the critical section. Then the thread exits. If you use object oriented code (CSingleLock for example) to manage the lifetime of critical section ownership then this problem should never happen. But if you manually control the locking, using say, CCriticalSection::Lock() and CCriticalSection::Unlock(), or EnterCriticalSection(&cs) and LeaveCriticalSection(&cs) then it’s possible for you to forget to leave a locked CS, or for a logic failure to result in a critical section not being locked.

If you’re using object oriented synchronization locking methods you might want to look at Thread Lock Checker to automate checking for some simple and common errors that can happen.

DWORD doThread(void	*param)
{
	EnterCriticalSection(&dataCS);
	
	doWork(data);
	
	return 0;	// forgot to call LeaveCriticalSection(&dataCS);
}

Incorrect exception handling

This is where some code in a thread is protected by an exception handler (you’re calling a 3rd party library, or working with data of unknown integrity) and a critical section is locked when an exception is thrown. In an ideal world the exception handler will leave that locked critical section. Unfortunately the writer of the exception handler may not known about the critical section, or they may have forgotten about it – either way the locked critical section doesn’t get unlocked. As with the previous case, if you use object oriented access to critical sections (CCriticalSection, CSingleLock) the process of unwinding the stack during the exception handling should automatically unlock these locks. This won’t happen if you’re using CRITICAL_SECTIONs with the Win32 API.

DWORD doThread(void	*param)
{
	__try
	{
		EnterCriticalSection(&dataCS);
	
		doWork(data);	// something inside here throws an exception. 
	
		LeaveCriticalSection(&dataCS);
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		// forgot to call LeaveCriticalSection(&dataCS);
	}
	
	return 0;	
}

Terminate Thread

This is where a thread that is doing some work that has accessed some critical sections is killed by another thread calling TerminateThread(). There are occasions where TerminateThread() can be useful, but this is a last ditch method for dealing with threads. If your code is using TerminateThread() to manage your own threads why not spend some time to work out how not to use TerminateThread and to make your threads end normally (by exiting the thread or calling ExitThread()).

// correctly written thread

DWORD doThread(void	*param)
{
	EnterCriticalSection(&dataCS);
	
	doWork(data);
	
	LeaveCriticalSection(&dataCS);
	
	return 0;
}

void mainThread()
{
	HANDLE	hThread;
	DWORD	threadId;
	
	hThread = CreateThread(NULL, 0, doThread, NULL, 0, &threadId);
	if (hThread != NULL)
	{
		doSomeWork();
		
		TerminateThread(hThread, 0); // this is a bit brutal
		CloseHandle(hThread);
	}
}

How to detect Abandoned Critical Sections?

We have two ways to detect Abandoned Critical Sections.

  • Thread Wait Chain Inspector
  • Thread Validator

Thread Wait Chain Inspector

Thread Wait Chain Inspector is a free software tool that we wrote that uses the Win32 Wait Chain API to identify various wait chain states of the locks and waits in a given application. Just select the application in question and look at the results.


This tool tells you process ids and thread ids, but it can’t give you symbols, filenames and line numbers. It will provide thread names if you’re working on Windows 10 and you’ve named your threads using the SetThreadDescription() API.

Thread Validator

Thread Validator is our thread analysis software tool for analysing thread synchronization problems, deadlocks, busy locks, slow locks, contended locks and recursing locks. We’ve recently added some reporting options to Thread Validator will help you identify the location of abandoned critical sections.

I’ve used the tvExample demonstration application that ships with Thread Validator (you’ll need to build) to deliberately create two abandoned critical sections. From the test menu choose “Exit thread with a locked critical section” and “Terminate thread with a locked critical section”.

The summary display will show an abandoned count of 2 in the Errors panel.


The various locks displays will colour the abandoned thread dark purple and list the Lock status as Abandoned


If you click the Abandoned bar in the Errors panel, the display will move to the Analysis tab and the callstacks for the abandoned critical sections will be displayed.


Expanding each entry reveals the callstacks so that you can see where see where each critical section is abandoned. Note that each entry shows two callstacks. The first is where the critical section was created. The second is where the critical section was abandoned. You can expand any entry on any callstack to see the source code.

Abandoned because of thread exit


Abandoned because of TerminateThread()


Expanding the callstack entries to reveal the source code…


Conclusion

Abandoned Critical Sections are bad news. They cause deadlocks. But they don’t need to be hard to track down when you’ve got the right tools to put to work.

Turbo Debugger Symbols Viewer

By , March 6, 2020 12:48 pm

If you’re using Delphi or 32 bit C++ Builder your compiler/linker produces symbols in TDS format. TDS means Turbo Debugger Symbols – it’s an old naming convention from the days of the Turbo compilers.

There are occasions when it’s useful to know what’s inside the symbol file. Is the symbol name as I expected? Or is it mangled to something else? Is the symbol name in the debug info? If not, then maybe the compiler optimised that function out of existence (it does happen).

We’d already written a symbol file viewer for Visual Studio PDB files. It seemed logical to write a similar tool for TDS symbols. That tool is TDS Browser.

TDS symbols can be stored in the executable to which they relate, or in a separate TDS file. The 64 bit version of Delphi doesn’t provide an option for symbols in an external TDS file, which is odd, as no one wants to ship symbols with their executable. But hey, Embarcadero must have their reasons, right? As a result to view symbols with TDS Browser you can specify the TDS file or the executable file, either way we’ll load the symbols if they exist.

Symbol name mangling is different for 64 bit symbols, so we’ve provided an option to see the raw, unmangled symbol name for the occasions when you need that.

You can sort the symbols by any column, and reverse the sort by clicking the same column again. This is useful for finding symbols with source files – sort by filename. Select a symbol and we’ll show you the source code and line numbers if we can find the source code (not easy for source files that don’t have complete paths).

We provided options for resolving addresses into symbols for the 4 main use cases:

  • Crash at absolute address in DLL.
  • Crash at relative address in DLL.
  • Crash at symbol relative address.
  • Crash data from Windows Event Log in XML format.

The above options are on the Query menu.


If the crash address can be resolved into a symbol, the symbol is selected, and the relevant source code and line number information is displayed. A context menu also provides additional options for highlighing symbols and copying symbol related information to the clipboard.


Here’s a short video showing how to use TDS Browser.

An easier way to view crashes in the Windows Event Log

By , March 6, 2020 11:45 am

In a previous article I wrote about how to identify crashes in the Windows Event Log.

You need to use the Windows Event Viewer, inspect each entry looking for some keywords then decode the XML data to get the information you want. All a bit slow, tedious and error prone.

So we wrote a tool to do that for you: Event Log Crash Browser.

Event Log Crash Browser scans your event log looking for crash events, then picks out only the information that is useful:

  • The executable.
  • The DLL that crashed (if it did crash in a DLL, rather than non-DLL memory).
  • The exception code.
  • The offset into the DLL of the crash location (or the location in memory for non-DLL crashes).
  • We also read the version information from the DLL so that we can identify the company responsible for the DLL that crashed.

You can sort on any column, and filter by exception type, executable and DLL.

It’s a really easy way to see what failures are happening on your machine. A lot more convenient than Windows Event Viewer. Looking at this machine I can see that the Visual Studio compiler, linker and IDE crash from time to time. I can also see that the WMI provider service dies quite often from a heap corruption – this is a core bit of Microsoft technology that has problems. Most of the other failures are related to the software under development and test on this machine.

Panorama Theme by Themocracy