[M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?

[Randy Coleburn]

Jay your message seems truncated again.
 
Threads have always worked for me in the past on Windows.  Do we have some sort of tests we can run to prove correctness of threading?  Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading.  Perhaps the problem lies in Juno and not threads.  Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem.  Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now.  In any event, I think some standard regression type tests would be in order here.  If we don't have them, perhaps Tony could offer some suggestions.  I would be glad to write some of these tests if given some general ideas on what to check for.
 
I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific."  Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly.  If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections.  If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3.  IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C.  After all, this mail list is for Modula-3 enthusiasts.  We wouldn't be spending time if we didn't think this language was great.
 
Regards,
Randy

>>> Jay K <jay.krell at cornell.edu> 9/22/2009 8:16 AM >>>

The problem with the Modula-3 code is the same as usual.
It is tedious, error prone, unsafe, not portable, target-specific.
Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3.
The other -- TimePosix.m3, probably ok.

Not tremendously so in this case, just a little.

The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it.




The C layer is also tedious and error-prone, and maybe unsafe,
  but it is portable and target-independent, which reduces
  but tedium and error-proneness.




Look at the Utime.i3 cloning/extension in the Modula-3 web browsers.
They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and
the result is that the safety guaranteeds are broken.




C code wouldn't have this problem. It would #include <time.h> and fail to compile.





Yes there is fairly definitely a problem on Windows and it dates, I think, to this change:





2009-02-16 02:20  hosking

  * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c,
    Csupport/little-endian/dtoa.c, convert/CConvert.i3,
    convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3,
    runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3,
    runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3,
    thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3,
    thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3,
    thread/WIN32/ThreadWin32.m3:

  Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics.
  This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held.
  RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not.





I'll have to reconfirm that I guess.
I had checked out and built the CVS tree at many dates/times, doing roughly
binary search, and narrowed it down to this.

Though Tony has undone this change.

I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well.



???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse).

It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.)

You know, if that succeeds, it pins the blame on ThreadWin32.m3.

If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere.




It /seems/ that Juno's pixmaps are getting copied over other data.




This change, I think, causes Juno to access violate whereas before it "only" failed assertions.

I believe it is considered fairly ok for a safe system to terminate with an assertion failure,
that might not be a bug at all, but considered far worse to hit a SIGSEGV

CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090922/0fd844bc/attachment-0002.html>