From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [BUG] copperlate/eventobj.c ->>> eventobj_inquire(), don't work References: From: Philippe Gerum Message-ID: Date: Fri, 10 Jul 2020 10:38:12 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Caffreyfans , xenomai@xenomai.org On 7/10/20 8:04 AM, Caffreyfans via Xenomai wrote: > Hi sir, > >     I'm trying to make another skin for xenomai.  When I do something about > "event". I use `eventobj_inquire()` to get event flags. But no matter what > value I post, I always get 0. > >     I find that eventobj_inquire() is not working. I know `alchemy/event` also > use `eventobj`. So I write a test code by using alchemy skin. I am curious > whether it is my own problem or there is an error in xenomai. > Most likely a bug in Xenomai. In addition, looking at cobalt_event_post(), there is a blatant race condition between the signal <-> wait operations. The in-kernel wait() operation serializes on the ugly big lock which is not going to help much against racing with the userland counterpart in cobalt_event_post(), which does this: __sync_or_and_fetch(&state->value, bits); /* full barrier. */ if ((state->flags & COBALT_EVENT_PENDED) == 0) return 0; The somebody-is-waiting bit tested above should be part of some atomic operation shared with the wait-side or covered by the ugly big lock, but the way it is implemented today can lead to spurious waits. The event code was fixed months ago for another bad issue, the whole thing looks fragile. You may want to review all of it. -- Philippe.