I just tried implementing it with event flags, and it works fine too, with no noticable performance difference.
Gary, I have studied the different options but I can't determine why this is a heavier solution. It seems like the only possible one. Any other method with condition variables ends up in a race condition deadlock. (Please correct me if I'm wrong though!) Just doing some more reading about the cyg_drv_cond_wait()... "Note that this function performs an implicit scheduler unlock/relock sequence, so that it may be used within an explicit cyg_drv_dsr_lock()...cyg_drv_dsr_unlock() structure." What if we did the dsr_lock/unlock around the while loop? I'll have to try it. Derek -----Original Message----- From: oliver munz @ s p e a g [mailto:[EMAIL PROTECTED] Sent: Thursday, February 16, 2006 11:47 AM To: Derek Bouius; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [ECOS] How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s... Thanks for the solution... Does this work whitout kernel? Would it be better to use event-flags? Thanks Oliver Munz ----- Original Message ----- From: "Derek Bouius" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, February 16, 2006 5:15 PM Subject: Re: [ECOS] How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s... >I am not registered for the mailing list, but peruse it once in a while, so >I am not sure if my mail will go through to it. Feel > free to repost it if it doesn't. > What we did to fix the locking issue was change the mutex to a semaphore. > See the patch. It seems to work reliably. > > Cheers, > > Derek > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
