Testing multi-threaded code

[Steven Collins]

I'm hoping somebody has a suggestion for a better way to write this kind of testing.

Presently in order to test multi-threaded code I have a mock for the pthread library, in particular for the mutex operations. in order to implement a class with resource(s) shared by multiple threads I end up defining an interface and writing a base implementation of the class without any protection of the resource(s). I then write a second implementation of the class that takes an instance of the interface and wraps mutex protection around the necessary methods. This allows me to do testing with strict ordering to ensure that the wrapped methods are called with the mutex held. What it also does is create a LOT of overhead and cause my peers to shudder at the thought of TDD. I myself hate all the complexity this introduces, but I don't see any simpler way to get the job done while having tests to prove the resources are properly protected.

[Ryan Hartlage]

In my (limited) experience, the best way to do this is to restructure
your code (I know, probably not what you were hoping for) in order to
ensure that all RT/OS interactions (threading, mutexes, semaphores)
are minimized and done through an extracted interface. Ideally, this
interface also makes it less obvious that you're actually interacting
with an RT/OS (for example, by doing most IPC through higher level
constructs such as message queues). Trying to shim TDD into existing
multi-threaded code that makes liberal use of RT/OS primitives
(necessarily or unnecessarily) without significant refactoring has
proven to be nearly insurmountable in all cases I've seen.

Ryan

> --
> You received this message because you are subscribed to the Google Groups
> "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cpputest+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Steven Collins]

This is new code being developed and includes the abstractions you're talking about so that higher levels don't have to worry about the locking. I could hack it together and do some hand waving, but I want this code under test too.

> email to cpputest+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "cpputest" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+unsubscribe@googlegroups.com.

[Bas Vodde]

Hi Steven,

I usually do two things:

- Seperate the multi-threaded logic as much from the domain logic. This is usually the most important.

- I tend to use mutex locking/unlock counting and balancing

So, for the second one, you can write a CppUTest plugin that will ensure every test has the same amount of locks as unlocks. Then in the test, I would just assert on the number of locks that occured. It isn’t great and doesn’t actually test the right things got locked, but it is very simple to do and doesn’t make your code more complex.

Hope that helps!

Bas

On 27 Mar 2017, at 10:26 PM, Steven Collins <spc.pro...@gmail.com> wrote:

I'm hoping somebody has a suggestion for a better way to write this kind of testing.

Presently in order to test multi-threaded code I have a mock for the pthread library, in particular for the mutex operations. in order to implement a class with resource(s) shared by multiple threads I end up defining an interface and writing a base implementation of the class without any protection of the resource(s). I then write a second implementation of the class that takes an instance of the interface and wraps mutex protection around the necessary methods. This allows me to do testing with strict ordering to ensure that the wrapped methods are called with the mutex held. What it also does is create a LOT of overhead and cause my peers to shudder at the thought of TDD. I myself hate all the complexity this introduces, but I don't see any simpler way to get the job done while having tests to prove the resources are properly protected.

--
You received this message because you are subscribed to the Google Groups "cpputest" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.