The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use \*strict IO\*. When compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages. But with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`. Tested under Mac OSX 10.8.2 and Linux. Tested with both GHC 7.6.1 and 7.6.2. I could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs +RTS -N2 -RTS to reproduce the bug. <details><summary>Trac metadata</summary> | Trac field | Value | | ---------------------- | -------------- | | Version | 7.6.1 | | Type | Bug | | TypeOfFailure | OtherFailure | | Priority | normal | | Resolution | Unresolved | | Component | Runtime System | | Test case | | | Differential revisions | | | BlockedBy | | | Related | | | Blocking | | | CC | | | Operating system | | | Architecture | | </details> <!-- {"blocked_by":[],"summary":"resource busy (file is locked) with multi-threaded file ops","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use *strict IO*.\r\n\r\nWhen compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages.\r\n\r\nBut with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`.\r\n\r\nTested under Mac OSX 10.8.2 and Linux.\r\nTested with both GHC 7.6.1 and 7.6.2.\r\n\r\nI could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs +RTS -N2 -RTS to reproduce the bug.","type_of_failure":"OtherFailure","blocking":[]} -->