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 Sep 19 '13 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. – Michael Shaw Sep 19 '13 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 Sep 19 '13 at 15:27
  • Are you limited to only one reference application? – Dan Pichelman Sep 19 '13 at 16:47
  • @DanPichelman Probably yes, due to budget / time constraints. – Vicky Sep 19 '13 at 18:53

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 Sep 20 '13 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 Sep 20 '13 at 9:05

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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