Arduino & thread

Brig:
probably the reason of the thread absence is due to the desire to direct the product to the general public, who perhaps had never even write a "hello world " ...

Have you read the reference I posted? Since I am assuming you didn't, I'll quote from the Abstract by Edward A. Lee:

Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism.

There are some serious objections to using threads, so I think it is unfair to claim that they have been omitted because it is a "consumer product" or that the designers stupidly did not think to include them.

For one thing, there is no hardware mutex provision, which is one of the ways you deal with synchronization issues. Second, even with a mutex (eg. implemented in software) you have the "deadly embrace" problem, where thread A locks resource X, and then waits for resource Y. Meanwhile thread B locks resource Y and then waits for resource X. Neither thread will continue, and the program stalls.

So you haven't magically simplified things, you have exchanged one lot of complexity (working with multiple items in a single thread) for a different lot of complexity (managing thread access to mutually-needed resources).

I don't know if the erudite arguments against "threads" are relevant here. The "protothreads" library that Brig is talking about isn't anything close to real threads...

I have based my project on RTC, which is updated by a method call in the code.

I gather that the idea is to have a sort of "background thread" that periodically synchronizes the Ardunio's idea of what time it is with an RTC/Calendar chip ? For purposes of fiddling with AC-controlled (60Hz) sockets and valves and things with relevant timescales based on thermal mass of several hundred pounds of water?

I agree with others that you're making this WAY too complicated. I would suggest getting rid of the Arduino-side "copy" of the clock entirely, and simply reading the time from the RTC whenever you need it. No more synchronization problems. And while reading the RTC may be "slow" compared to other AVR operations, I strongly suspect that it is plenty fast even compared with the 60Hz AC frequencies involved...

Another way of looking at it, is an Arduino has about the same amount of grunt as a 70's or early 80's home computer, they didn't do threads then, the arduino doesn't do threads now (at least usably).

I never said that the creators of Arduino have foolishly entered the thread. I said that because something is non-trivial operation and that not all programmers (particularly novice ones) know how to master in order to simplify the life they have not been included.
Or just as likely not have made them because of the small size of the memory & co.

The KISS principle I know him well, and I do not create great difficulty managing small little thread as I wanted to do, not to mention the problem of dead lock ... I should not have to face because I needed a single mutex ...

I think we should not talk about my project & thread, but only the thread, because they can be used independently of the project.
For that reason I had asked arduino & thread, not my project & thread

As Told by westfw the idea is to have a thread that updates the variables "time" of my project with those that are given by the RTC, because he seemed a natural thread that was dedicated to reading and then update the program variables

Without a doubt my difficulty in explaining, and no command of English are points down in the debate, and as such should focus on the thread in general.
If you understood that to maintain a small and inexpensive processors have not been made ??I'm fine, I just wanted to understand why I had not heard.

Brig, while I find the (software) threads concept quite fascinating, after reading this (interesting) (forum) thread I still can't understand what is wrong about "polling" the RTC time inside loop().
If you want to practice with threads on the Arduino, fine. But if your main goal is use the Arduino to manage an acquarium, then do yourself a favor and totally forget about threads.
There is the excellent Time library, which maintains the current time either via millis() or communicating with an RTC clock via I2C. This is 99% transparent, i.e. you can code to it and switch back and forth from an RTC to a RTC-less sketch in no time.
It's an excellent choice for periodic tasks.
Other libraries exists in the Playground that are equally good, although not as complete.

HTH

for didactic reasons I got used to the thread, and as long as this simple things I immediately use they natural ...

I repeat, my problem is a particular case, but should be seen in a wider range, where perhaps one can also do something nice ...
For example, alter the input from the numeric keypad (the phone), leaving a thread waiting on readChar even do a poll ... I find it more appropriate

and then repeat, not a problem, insert the line "RTC.refresh ()" it's just that I would rather not do it, because a programmer who uses my library can forget it, and before finding this little error... while if launch a thread that makes it alone, putting a mutex from Lokke on each access to the variables of RTC ... would be more simple and straightforward ...

personally if I had time, more knowledge of assembler and C more knowledge in general, I'll try to implement them willingly thread on arduino as good exercise!

In general, the problem with multithreading on a small microcontroller like the AVR is that there is not enough RAM. A complete process context (32 registers + PC + stack + stack pointer is probably over 100 bytes, and the atmega328 chip used on Arduino only has 2k total.

May I suggest a couple of links:

DuinOS, a FreeRTOS port to the Arduino platform:

http://www.multiplo.org/duinos/wiki/index.php?title=Main_Page

The QP framework (you can find it in the Playground, too):

And add to those 2, QNX which has been implemented on many much slower processors than the ATMEGA328 and which is running thousands of automatic machines of one kind or another in industry today.

Other viable RTOS kernels have been implemented on processors from the 6502/6800 onwards. I even wrote one in 1980 that pretty much worked :slight_smile: And I wrote lots of EDX based code on Series/1 with only 64K of memory, in the same era.

The main points about 'threads' or 'tasks' like: "Threads, as a model of computation, are wildly nondeterministic" is an argument against nondeterministic coding, not threads. This is exactly why the QP Framework is based on the idea that all threads MUST be Finite State Machines. This is a concept that I was able to enforce (Oh, Um, technically lead?) in Semiconductor manufacturing in one IBM plant in the 1990's.. and it DID decrease the instances of "wildly nondeterministic" code. Requiring that network communications interfaces to process equipment be documented as Finite State Machines was finally accepted practice. One grudging response was "I think we wasted some time using (this method) but it did make debugging a lot easier".

That said, I DID write a communications protocol using the approach which seemed to work OK and went into production and after it was running on about 20 systems for a few months it became clear that it occasionally crashed. Ugg... Finally my friend Tony Burke (Who I am glad to credit years later!!!) found the bug.

So nothing is sacred and nothing is perfectly error free.

In a similar way, Proof is in the nontrivial application running clean for 1000 hours. Anyone writing some QP FRamework stuff on the free Arduino version? I HOPE to get some time on this even though I should be writing other stuff. "But Mom, I LOVE writing RTOS stuff =( =( it's SO cool." And the .NET guys and the IphoneAPP guys don't know WHAT the hell you're even talking about...

QNX which has been implemented on many much slower processors than the ATMEGA328

How do you figure? I thought the smallest thing QNX ran on was a relatively good-sized x86?
In any case, "slow" isn't the problem. RAM is the problem. There are lots of nice multitasking systems that run fine on a system with 256K of RAM, but will have big problems on a system with 256K of flash and 8k of RAM...

westfw:

QNX which has been implemented on many much slower processors than the ATMEGA328

How do you figure? I thought the smallest thing QNX ran on was a relatively good-sized x86?

Maybe I'm older than you :wink:

Today QNX is supported on ARM, PowerPC and X86 etc, and now on the Blackberry Tablet :slight_smile:

But 25 years ago QNX did run on some of the earlier microprocessors that existed then. I'll try to find a reference, other than my recall of semiconductor process equipment running it...

Modern QNX has features that could never be supported on machines with very limited memory...

But the QP framework has working examples running on Arduino, so they have some stuff figured out for 2011.

I'd mainly like to see some set of known solutions for Arduino beginners to start to encounter apparent concurrency without going back to school to learn about interrupt latency and directed graphs.

We used QNX for building control on a 6809-based computer in the 80s, I don't remember the details but it's probably fair to say it had 64k RAM.

One assumes though that QNX has gone the bloatware track like everything else.


Rob

Ah, the old 6809. I like the Wikipedia article about it, in particular the HCF instruction (Halt and Catch Fire).

I don't suppose the Atmega has one of those?

Graynomad:
We used QNX for building control on a 6809-based computer in the 80s, I don't remember the details but it's probably fair to say it had 64k RAM.
...

Thanks for validating that my personal memory is still retrieving! Hadda be someone associated with "Gray", I guess..

And then there was XPR (eXecute PRogrammer) LDN (LoaD Nothing) and a lot of other funny ones around a few years ago.


Rob

Here's a comparisons of RTOS possibilities for Arduino: http://www.out--there.com/blog/rtos-for-arduino/

And then there was XPR (eXecute PRogrammer)

My personal favourite was the PowerPC's EIEIO instruction

That was on the Old MacDonald variant of that processor wasn't it?


Rob

AWOL:
My personal favourite was the PowerPC's EIEIO instruction

So you are not referring to:

A "computer bought the farm" message is an error message displayed on GNU Hurd when one of the servers that provide kernel-like functions reaches a "hopeless" situation (after which it is usually terminated). This is a rough equivalent of a kernel panic in monolithic Unix-like kernels. Its corresponding error code is the Hurd-specific EIEIO, a reference to the folk song Old McDonald Had a Farm.

But rather:

Enforce In-Order Execution of I/O is an assembly language instruction used on the PowerPC computer processor used to prevent one memory or I/O operation from starting until the previous memory or I/O operation completed.

So, "do things in the order I tell you to"?