[M3devel] awful race condition in libm3/FilePosix.m3?

[Rodney M. Bates]

On 01/30/2013 02:24 AM, Jay K wrote:
> I commited a fix. But two questions:
>
> 1) why not just stat, instead of open, fstat, close?
>
> 2) a lighter weight way to fix this than I did?
> In particular:
> a) VAR m := NEW(MUTEX);
> can we at least say VAR m: MUTEX instead? I tried. It crashed.

I would expect this to crash because m would be default initialized to NIL,
which when dereferenced, would show up as a segfault, in any M3 implementation
I have experience with.

Actually, the language only says it has to be initialized to a bit
pattern that represents some member of the type.  But for or any reference
type, the only sensible choice for a compiler to make would be NIL.

Perhaps we should change the language to say this explicitly?  I am
very confident it wouldn't undermine either any existing code or compiler,
and might save some grief in the future.

>
> b) some notion of a "once"? a lock that will only be successfully entered once, for one-time initialization, all other attempts to enter wait for the first enterer to leave, and the it is never entered again. pthreads has this. Win32 since Vista has it (I'd still provide something compatible to pre-Vista, but it can be done easily enough.
> They are faster and perhaps smaller than other kinds of locks.
>

I shouldn't be hard to wrap these with an interface.  Lots of people have
agonized over the performance hit every time of "has it been done once".

>   - Jay
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 --
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Wed, 30 Jan 2013 07:40:02 +0000
> Subject: [M3devel] awful race condition in libm3/FilePosix.m3?
>
> FilePosix.m3:
>
>
> I'm not 100% sure, but looks really bad.
> I suspect it will close arbitrary files out from other threads.
> Notice there is absolutely no mutual exclusion.
> An arbitrary number of threads will run here, mostly succeeding, but not necessarily.
>
> VAR
>    null_done := FALSE;
>    null_stat: Ustat.struct_stat;
>    null_fd: INTEGER;
>
>
> PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} =
>    VAR result: INTEGER;
>    BEGIN
>      IF NOT null_done THEN
>        null_fd := Unix.open(M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw);
>        IF null_fd < 0 THEN
>          null_done := TRUE;
>          RETURN FALSE
>        ELSE
>          result := Ustat.fstat(null_fd, ADR(null_stat));
>          EVAL Unix.close(null_fd);
>          IF result # 0 THEN
>            null_fd := -1
>          END
>        END;
>        null_done := TRUE;
>      END;
>      RETURN null_fd >= 0 AND statbuf.st_rdev = null_stat.st_rdev
>    END IsDevNull;
>
>
>   - Jay