Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Atomicity in the MF

Started by Mario Vernari, Oct 17 2011 07:26 AM

Prev

Please log in to reply

25 replies to this topic

#21 georgejh

Advanced Member

Members
87 posts

LocationGlasgow, UK

Posted 20 October 2011 - 05:04 PM

If there is a disagreement here, it may be about what each of us regards as "safe". I read the above as a description of the NETMF's current behavior, and not a promise that it will always behave so.

I agree on the general description when read the details you see that current PAL operates in our safe side. Anyway, I think used properly, there is not danger of multithreading with .NETMF.

Back to top

#22 Stefan W.

Advanced Member

Members
153 posts

Posted 20 October 2011 - 05:20 PM

Go here and read "Introducing the .NET Micro Framework" and "Porting the .NET Micro Framework". Those must be quite still valid if they are on the main .NETMF site. Don't they?

Let's look on some of them:
[snip]

This still gives no guarantees. It describes the current implementation, as Corey says. It's like the code in http://en.wikipedia....iew_of_the_code - this works (on a specific subset of machines), but it is based on assumptions that are not guaranteed by the language, so a program containing it does not neccessarily work on other implementations.

That '.NET MF is "cooperative-ish-ly multitasked." So IL instructions are executed individually.' was already stated in the very first reply from Chris, but the follow-up question is if it's guaranteed, and I have seen no guarantee to that point.

I believe that no discovery of fact, however trivial, can be wholly useless to the race, and that no trumpeting of falsehood, however virtuous in intent, can be anything but vicious.
-- H.L. Mencken, "What I Believe"

Back to top

#23 Mario Vernari

Advanced Member

Members
1768 posts

LocationVenezia, Italia

Posted 20 October 2011 - 05:35 PM

This is too hard for me, guys...you are talking in Chinese! Anyway, I believe you both are saying the same thing using different words. From *my* perspective, I wouldn't rely on a particular implementation: this is C# and must behave as C# even on a desktop machine. That is: if I copy-and-paste the MF code on a desktop machine, the program MUST behave exactly as the MF. (Libraries apart) Otherwise it would be C++, not C# (meaning .Net as platform). What I mean from all your posts, is that it's better to treat the code as it was on a multicore desktop PC. This should be safer for the portability of the code, even (maybe) a bit overloading. Thank you all, anyway! Cheers

Biggest fault of Netduino? It runs by electricity.

Back to top

#24 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 20 October 2011 - 06:17 PM

Here we are talking about .NETMF and not for C# language specification (small but very significant difference).

This is precisely the point, I think. I have the choice to use the C# specification as basis for my programs, or to use the NETMF specification. Ahhh, wait. There is no single, binding document that claims to be a NETMF specification...

There are just a couple of descriptions how NETMF is currently implemented. As Corey says, this is not a promise in any way. And the problem of having no authoritative NETMF specification is obvious: if we had one, this discussion would be much shorter and the result clearer. After all, which of the mentioned documents should we consult, and how can we be sure we have studied all relevant documents?

I would love to see a NETMF specification that specifies the differences between full .NET and NETMF more precisely and more completely, and in one single document that doesn't distract with obscure descriptions of how the stuff is actually implemented. I shouldn't have to read the porting kit documentation to figure out which assumptions I can make, and which ones not. I bet there are subtle differences that practically no one is aware of. For me, that's the really bad thing: creating dependencies on some possibly temporary NETMF-specific behavior, without even being aware of. If I am aware of the differences, then it's my decision and I know that unpleasant surprises later on are possible. That's perfectly ok.

So for me it's ok (although not desirable) if there are differences between full .NET and NETMF, as long as they are described clearly, completely, in one single document, and with some promise by Microsoft that it stays that way in the next releases. Then I can make an informed decision whether I want to rely on NETMF-specific behavior or not, rather than just hope for the best.

Back to top

#25 Corey Kosak

Advanced Member

Members
276 posts

LocationHoboken, NJ

Posted 20 October 2011 - 07:31 PM

I would love to see a NETMF specification that specifies the differences between full .NET and NETMF more precisely and more completely,

Agree. There are some really drastic differences, like the handling of the NUL character (i.e. (char)0) in strings, and the rules for static initialization, that are radically different. I can never tell if these differences are bugs or features :angry:

Back to top

#26 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 20 October 2011 - 08:07 PM

Agree. There are some really drastic differences, like the handling of the NUL character (i.e. (char)0) in strings, and the rules for static initialization, that are radically different. I can never tell if these differences are bugs or features

Yes, and some subtle ones. For example, we like to avoid unnecessary allocations in our programs. No wonder, when we have so little RAM available. So we need to know exactly when memory is allocated. Not easy, C# does a lot of implicit allocations. But ok, if you are careful, you can manage. But surprise, NETMF does allocations (it was in a small and innocent benchmark program - thousands of unnecessary allocations...) where it must not, according to the CLI specification...

My colleague Beat created an issue on the Codeplex issue tracker (issue). He ended with "If these issues cannot be fixed ... they must be clearly documented". Well. Not fixed, issue closed, nothing documented (as far as I can tell). :angry: