Protothreads: Lightweight Stackless Threads in C

by signa11 • 7 years ago

163 42 7 years ago

saagarjha2• 7 years ago

These seem to work with some clever (ab)use of switch statements: http://dunkels.com/adam/pt/expansion.html

greiskul• 7 years ago

Wait, how does this work with local variables? Wouldn't the scope be destroyed when you returned, how can it restore the stack if it doesn't save information in the local continuation?

User23• 7 years ago

The article mentions Duff's Device. And yes it works.

webstrand• 7 years ago

If I understand it correctly, it doesn't. That's why they're called stackless threads. Variables local to the stack frame lose their state, so any internal state needs to be stored in a global.

saagarjha2• 7 years ago

It doesn't: http://dunkels.com/adam/pt/about.html

fjfaase• 7 years ago

Indeed, there is a problem with local variables. The example relies on using global variables. If you want multiple threads executing the same function, it is not going to work. Also there is no solution for calling other functions (and have them switch in the middle). A long time ago, I worked on an implementation that does not have these limitations. See: http://www.iwriteiam.nl/Ha_cmt.html

mrpippy• 7 years ago

That was the original implementation (and still used for non-GNU C).

On GCC and Clang though, labels-as-values allows a cleaner implementation: https://github.com/Akagi201/protothreads/blob/master/include...

dividuum• 7 years ago

Woo. I wrote the original implementation for that 14 years ago. I discovered local labels when we tried to write some code that used the had multiple yields in the same line. Due to how the switch based implementation worked, this wasn't possible, so I looked for other solutions.

kitd2• 7 years ago

IIRC when Simon Tatham first proposed the mechanism, he suggested it should never be used in production, and whoever does so should be fired!

baybal22• 7 years ago

Adam is a CEO of Thingsquared =D

dnlgl• 7 years ago

Quite the opposite, actually. He said that he will probably be fired, but should still insist on it being the right way: "Any coding standard which insists on syntactic clarity at the expense of algorithmic clarity should be rewritten. If your employer fires you for using this trick, tell them that repeatedly as the security staff drag you out of the building." https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

networkimprov• 7 years ago

Related: Go-style concurrency for C, http://libmill.org/

alexhutcheson3• 7 years ago

Although note that all libmill coroutines are mapped N:1 to OS threads, while goroutines are mapped M:N to OS threads. In other words, libmill won’t let you have run 2+ coroutines simultaneously on different OS cores, but Go will allow that.

danappelxx3• 7 years ago

In fact, this means that writing concurrent code is easier as you don’t have to worry about synchronizing access to shared state. It also means scaling applications is straightforward, since you are forced to design for horizontal scalability from the get go (similar to deploying node.js). Ive always found it strange that Go has both channels and locks as synchronization primitives.

chadcmulligan• 7 years ago

is there an iOS port you'd know of - couldn't find one

photojosh3• 7 years ago

I wrote an entire I2C stack for an 8-bit microcontrolller using this protothread library.

I would highly recommend using an RTOS instead. ;)

sgillen• 7 years ago

any chance that code is up somewhere? Sounds interesting

baybal22• 7 years ago

My guess is following: some people will put in doubt the rationale of using threads for embedded development as such.

See, MCUs are much more interrupt driven than today's PCs, when it comes to I/O, and don't have to run interface logic as it's usually done in hardware.

You can make a widget feel quite snappy and interactive even with very simple linear code.

For the few tasks genuinely requiring real parallelism, or programming fancy multicore MCUs, it will likely be that you will need more than just thread separation, and it is better to do it properly than use hacks — in other world, use process separation and let complexities be handled by the OS.

photojosh3• 7 years ago

I never cleaned it up for release, but if you email me I could send through some interesting bits of it.

I2C and the peripheral we were dealing with is quite stateful, and writing the access code in a synchronous fashion wasn't possible due to overrunning other constraints. It seemed like a good idea at the time. The sibling comment has it pretty right... it would probably have been quicker in the end to go to an RTOS.

That said, I'm still fairly proud of the I2C state machine that runs in the interrupt handler– it was completely separate from the protothread code that layered over the top.

It's in a few microcontrollers in products we do, the funkiest is the smallest standard AVR package you can get, which imitated an obsolete tiny I/O expander chip we had to replace on a 6mm wide PCB. That was using I2C slave mode, but we could then run the entire sensor interfacing on that board rather than using a separate micro.

avodonosov• 7 years ago

How does it work?

jlundberg• 7 years ago

The following page describes the implementation details: http://dunkels.com/adam/pt/expansion.html

huxingyi• 7 years ago

Inspired by Protothreads, I implemented a similar framework 5 years ago, well, not exactly a framework, just several lines of macros, which could be used in general purpose not just embedded system (I am not sure if Protothreads can be used in general purpose). I used it in product environment with libuv, here is the github link: https://github.com/huxingyi/c-block

MrBuddyCasino• 7 years ago

If "running multiple tasks on an embedded system that share a stack" sounds interesting to you, Rust's RTFM is actually quite clever[0]. It only works on ARM MCUs right now, but tasks are IRQ triggered, have a priority, memory safe, deadlock-free and have very low overhead. Scheduling is done in hardware via the interrupt controller.

[0] https://github.com/japaric/cortex-m-rtfm

srfilipek• 7 years ago

I hate protothreads with a passion.

Not because of what they do (it's a neat trick), but because it teaches bad development practices to programmers.

I had a junior programmer "correct" me on some embedded code saying that all my local variables should actually be declared static, because in their experience "static is the way to go".

This "embedded" system was actually running Linux, using proper threading semantics.

marssaxman• 7 years ago

That's a matter of using the right tool for the environment, though, isn't it? Someone looking at the world from the small-system, bare-metal embedded development perspective might express similar feelings about garbage collection, for teaching junior programmers to be unacceptably sloppy about memory management.

I think it is simply to be expected that junior programmers will frequently pick the wrong tool for the job, for any job in any context, as they have not yet had time to master many tools and do not yet have enough experience to understand the edges of their ignorance. (Presumably we would start thinking of them as peers and calling them "senior programmers" at some point along this journey of growth...)

Protothreads: Lightweight Stackless Threads in C

Related Stories