Hi, After a bit of investigation we have found that removing the call to cyg_libc_stdio_flush_all_but from Cyg_StdioStream::refill_read_buffer prevents the dead lock.
What is the reason for having the call to cyg_libc_stdio_flush_all_but when any stream is being read? Thanks in advance Mark Retallack -----Original Message----- From: ecos-discuss-ow...@ecos.sourceware.org [mailto:ecos-discuss-ow...@ecos.sourceware.org] On Behalf Of m...@retallack.org.uk Sent: 30 November 2010 15:08 To: ecos-discuss@ecos.sourceware.org Subject: [ECOS] cyg_libc_stdio_flush_all_but deadlock Hello everyone, A fix has been applied to eCos to stop a crash: http://sourceware.org/ml/ecos-patches/2009-01/msg00011.html This fix added a Mutex lock around the Cyg_libc_stdio_files::files table, however in adding this, it has added a dead-lock situation. I have found that this topic has been discussed in the past without a conclusion: http://sourceware.org/ml/ecos-discuss/2003-12/msg00272.html I have found that if there are two thread (thread1 and thread2) both read and write to separate file pointers using the fread and fwrite commands. The system can end up in a dead lock situation where thread1 has locked the Cyg_libc_stdio_files::files_lock and then locks the other threads stream lock (from the cyg_libc_stdio_flush_all_but call). If thread2 is also performing the cyg_libc_stdio_flush_all_but call at about the same time, then the stream lock is already locked and thread2 then blocks waiting for the Cyg_libc_stdio_files::files_lock lock. Both threads are now locked waiting for each other to finish. I have looked through the code and have been unable to see a clean way to fix the problem. Does anyone have a good suggestion to fix the problem? Thanks in advance Mark Retallack -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
