This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s...


I think cyg_drv_dsr_lock() will block the loop, because You need the DSR to update the variable and to release the wait-funcion.

I think, the best option may be to modify the condition cyg_drv_cond_wait() so, that it rememers an signal after the initialisation. If so, it would work fine.

I don't know, where it is interessting to forget signals...

Oliver


----- Original Message ----- From: "Derek Bouius" <derek.bouius@sympatico.ca>
To: "'oliver munz @ s p e a g'" <munz@speag.ch>; <andrew@lunn.ch>
Cc: <ecos-discuss@sourceware.org>
Sent: Thursday, February 16, 2006 9:07 PM
Subject: RE: [ECOS] How to debug synchronisation in the usbs.c in a new usb-driver for the ARM at91sam7s...



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


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]