Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003910OCamlOCaml generalpublic2005-12-05 21:112005-12-07 13:46
Reporterpbljung 
Assigned Toxleroy 
PrioritynormalSeverityblockReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.08.3 
Target VersionFixed in Version 
Summary0003910: mingw blocks using 2+ threads / unix works ok
DescriptionUsing 1 pair of a sender/receiver threads to synchronize & communicate works fine using ocaml mingw -threads (downloaded precompiled version). However using 2+ independent pairs blocks under mingw. Either Thread.join or Event.sync is not working as expected in mingw ocaml.

Note that using an arbitrary number of thread pairs works fine using linux and macosx using either -threads or -vmthreads.

Also note that multiple threads writing to stdout on mingw results in interleaved/garbage output; running on unix results in (desired) non-interleaved output. Removing all printf statements still results in blocking, indicating that this is a separate issue.

% ocamlmktop -thread -custom -o threadtop unix.cma threads.cma -cclib -lthreads -cclib -lunix
% ./threadtop -I +threads
        Objective Caml version 3.08.3
# Sys.os_type;;
- : string = "Unix"
# #use "multithread2.ml";;
val sender : int Event.channel -> unit = <fun>
val receiver : int Event.channel -> unit = <fun>
1 reading
2 sending
2 done
1 read v=2
done all
- : unit = ()
# #use "multithread4.ml";;
val sender : int Event.channel -> unit = <fun>
val receiver : int Event.channel -> unit = <fun>
3 reading
4 sending
4 done
5 reading
6 sending
6 done
3 read v=4
5 read v=6
done all
- : unit = ()

Running the above tests fails on mingw! CtrlC does not work, and threadtop must be manually terminated.
$ ocamlmktop -thread -custom -o threadtop unix.cma threads.cma -cclib -lthreads -cclib -lunix
$ threadtop.exe -I +threads
        Objective Caml version 3.08.3
# Sys.os_type;;
- : string = "Win32"
# #use "multithread2.ml";;
val sender : int Event.channel -> unit = <fun>
val receiver : int Event.channel -> unit = <fun>
1 readin2 sending
g
2 done
1 read v=2
done all
- : unit = ()
# #use "multithread4.ml";;
val sender : int Event.channel -> unit = <fun>
val receiver : int Event.channel -> unit = <fun>
3 readin456 srseeenandddiiinnngg


43 done
read v=4
g
6 d5 read v=6
one
Additional Information% cat multithread2.ml
let sender c =
  let id = Thread.id (Thread.self()) in
  Printf.printf "%i sending\n" id; flush stdout;
  Event.sync (Event.send c id);
  Printf.printf "%i done\n" id;
  flush stdout;;

let receiver c =
  let id = Thread.id (Thread.self()) in
  Printf.printf "%i reading\n" id; flush stdout;
  let v = Event.sync (Event.receive c) in
  Printf.printf "%i read v=%i\n" id v; flush stdout;;

let c1 = Event.new_channel() in
let t1,t2 = Thread.create sender c1, Thread.create receiver c1 in
List.iter Thread.join [t1;t2];
Printf.printf "done all\n";;

% cat multithread4.ml
let sender c =
  let id = Thread.id (Thread.self()) in
  Printf.printf "%i sending\n" id; flush stdout;
  Event.sync (Event.send c id);
  Printf.printf "%i done\n" id;
  flush stdout;;

let receiver c =
  let id = Thread.id (Thread.self()) in
  Printf.printf "%i reading\n" id; flush stdout;
  let v = Event.sync (Event.receive c) in
  Printf.printf "%i read v=%i\n" id v; flush stdout;;

let c1,c2 = Event.new_channel(), Event.new_channel() in
let t1,t2,t3,t4 = Thread.create sender c1, Thread.create receiver c1,Thread.create sender c2, Thread.create receiver c2 in
List.iter Thread.join [t1;t2;t3;t4];
Printf.printf "done all\n";;
TagsNo tags attached.
Attached Files? file icon multithread4.ml [^] (635 bytes) 2005-12-05 21:11 [Show Content]

- Relationships

-  Notes
(0003420)
xleroy (administrator)
2005-12-07 13:44

Behavior reproduced in 3.09.0 both with Mingw and MSVC versions.
The deadlock is in the final Thread.join operations, not in the event-based
communications.
The problem goes away if threads are created with CreateThread instead of
beginthread. Possibly, the early closing of the thread handle performed by
beginthread causes a concurrent WaitForSingleObject to hang.
Applied the fix above to otherlibs/systhreads/win32.c in 3.09 bugfix branch.

- Issue History
Date Modified Username Field Change
2005-12-05 21:11 pbljung New Issue
2005-12-05 21:11 pbljung File Added: multithread4.ml
2005-12-07 13:44 xleroy Note Added: 0003420
2005-12-07 13:46 xleroy Assigned To => xleroy
2005-12-07 13:46 xleroy Status new => closed
2005-12-07 13:46 xleroy Resolution open => fixed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker