Usefulness of Lockfree programming on Userlevel Threads

3
votes

AFAIK, as opposed to time-slice based scheduler preemption, pure User-level threads(ULTs) have the property of yielding the processor to the other threads. However, from my surfing on internet I see that we have several preemptive User Thread mechanisms now.

Keeping this in mind, wanted to start a discussion on benefits of Lock-free programming on User level threads. My understanding is that irrespective of presence of preemptive scheduler performance of Lock free programming should surpass that of mutex/semaphore based programs.

However, I am still confused; since acquire operation on mutex also takes fast-path in the absence of contention, performance gain need not be attractive enough to migrate to Lock-free approach.

In case of semaphores, there is a invocation to system call leading to context switch and hence lock-free approaches can be seen as much better option.

Please suggest for both the situations - ULT equipped with preemptive mechanism and the one without it.

1
multithreadinglock-free
Do you have an actual code or design problem that you wish to solve? - Martin James
I am afraid. Actually NO. I am working for a company that uses User Level Threads and has preemptive library. There are several data-structures including some that allocate(use) memory from preallocated heap which is designed a Radix Tree. I am just cautious and curious whether to go for Lockfree approach. - ultimate cause
What do you mean by "lock-free programming"? If you do IO then you will eventualy need locks, no matter what the architecture is. - freakish
@freakish - I am not sure I get you. By Lock-free I mean lock free approach to regular insert/delete/read operation on data-structures. Did you mean that we need to protect a descriptor by synchronization mechanisms and that is why we need locks while I/O? - ultimate cause
You cannot have one without the other. Whatever "lock-free" low-level primitive you use is never going to cause the operating system's thread scheduler to cause a context switch. You really do need a semaphore or mutex when blocking is required and/or good concurrency is desired. Once you start bolting a yield on top of a failed CAS then you are no longer ahead. - Hans Passant

1 Answers

1
votes

This is not an easy question to answer, as it is very general, it will boil down to what your requirements are.

I have recently been working with systems where the use of lock free structures was considered, but when we sat down and wrote out our requirements, we realized that they are in fact not what we want. Our system didn't really require them, and in fact locking helps us because we typically have a producer/consumer architecture where if there is nothing being produced (i.e. nothing being added to a queue) then the consumer should be idle (i.e. blocked).

I recently wrote about this in more detail: http://blog.chrisd.info/a-simple-thread-safe-queue-for-use-in-multi-threaded-c-applications/