I want to provide some library functionality and a reference application, which will run on a fully-featured, POSIX-compliant platform. The app and library will need bi-directional serial port communication, user input from keyboard, user display to text console, and probably timers.

I also want to provide a porting guide so that users of the library can port it (with or without the reference application) to their own platforms, which may be POSIX-compliant or not, and may or may not support multiple threads.

I am taking care of the main platform portability issue by writing portable code for everything as far as possible and providing a self-contained porting layer for platform-specific code. In my porting guide I will tell the user to replace the porting layer functions with implementations for their own platform.

However as far as the threading model goes, I have two choices:

  • implement my reference application as a very simple single-threaded program (main loop would poll keyboard, poll serial port, check timer status, and call library functions as needed)
  • use the pthreads library and have a main app thread with separate threads for user input, serial port receive, and timer expiry, all of which would post messages to my main app thread for processing.

Whichever model I choose I will have to explain to users how to port it to a platform which may be using a different model.

Even if I use a single-threaded implementation for the reference app, I will make sure any library functionality is re-entrant (or put big caveats around it if that isn't possible).

What considerations should I bear in mind, in my implementation and the porting guide? What information would you want if you were porting some multi-threaded code to a single threaded system, or vice versa?

  • (I've tried quite hard to keep this factually answerable rather than a subjective "which way is better" approach. But if you feel it's too subjective we can discuss how best to edit it!)
    – Vicky
    Commented Sep 19, 2013 at 15:11
  • its not clear on where the boundary is between your app and the library. This is important as its the library you need to be thread safe. Commented Sep 19, 2013 at 15:24
  • I will either make sure the library is thread-safe, or if that is not possible (not clear yet) I will make sure the reference app includes protection around any non-thread-safe library functions. I don't think it's really the library that's the problem - it's more those users who might wish to start with the reference app, port it to their own platform and then adapt it for their own purposes.
    – Vicky
    Commented Sep 19, 2013 at 15:27
  • Are you limited to only one reference application? Commented Sep 19, 2013 at 16:47
  • @DanPichelman Probably yes, due to budget / time constraints.
    – Vicky
    Commented Sep 19, 2013 at 18:53

2 Answers 2


As with all multi-threaded development, the introduction of multiple threads means the following need to be managed:

  1. Managing concurrent access to shared resources to ensure consistency
  2. Design of locking strategy to prevent deadlocks
  3. Managing of resources that are thread locked. (e.g. can you read your serial port from multiple threads at the same time?)
  4. Shutdown / Error handling. This can introduce many unexpected code paths, do resources always get properly released, can deadlock occur?

I'm not seeing a particular problem with doing all this on a single thread, as keyboard and serial can be made essentially non-blocking. It all comes down to your library, and how long do the function calls in your library take to complete?

  • See my comment to kevin cline's answer - I know I can do all this on a single thread, and it won't be a problem. I'm just considering the ease of portability for users. (I should have added that users will have the source code as well, but I don't want them to NEED to change the library code).
    – Vicky
    Commented Sep 20, 2013 at 9:07

There is no reason to introduce multi-threading just because you need to react to multiple input sources. You can wait for the keyboard, serial port, and timer via the POSIX select system call. If you are using C++, then you could use the ACE library Reactor.

  • I realise it's not necessary to have multi-threading in the reference app. What I'm trying to consider is whether it's easier, for someone who wants to port the library with or without the reference app) into their own system, is it easier if what I have provided is single-threaded or not?
    – Vicky
    Commented Sep 20, 2013 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.