From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e53617e6821a1c7e
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-04-30 01:04:10 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!dialin-145-254-038-216.arcor-ip.NET!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Suspicious reentrant semaphore
Date: Wed, 30 Apr 2003 10:06:06 +0200
Organization: At home
Message-ID: <b8o01n$bh20l$1@ID-77047.news.dfncis.de>
References: <MPG.19191554aff631919896ed@News.CIS.DFN.DE>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: dialin-145-254-038-216.arcor-ip.net (145.254.38.216)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Trace: fu-berlin.de 1051689848 12093461 145.254.38.216 (16 [77047])
User-Agent: KNode/0.7.1
Xref: archiver1.google.com comp.lang.ada:36757
Date: 2003-04-30T10:06:06+02:00
List-Id: <comp.lang.ada>

Jano wrote:

> I'm developing a multitasking program that runs OK for several hours. At
> some indeterminate moment, a bunch of its tasks cease to respond, and I
> have a strong suspicion that the culprit is a semaphore package I've
> done.
> 
> The purpose is to have a semaphore which can be called more than a time
> _by the same task_, and that must be released the same amount of times.
> Nested calls, simply.
> 
> Leaving aside why I have done that (yes, poor design, I'm removing it
> anyway ;-), I would like to know if my package is right or really is
> there some race condition. Please comment on it. I know that
> Current_Task shouldn't be called inside entries (in fact Gnat doesn't
> allow it, I tried :-P) but doesn't complain about it being used in
> barriers. Anyways, I have a (maybe wrong) feel about that being related
> to the deadlock.

The requeue statement does the trick in case you want to use a parameter 
value in a barrier. You could add one more private entry and requeue to it 
if the task is not the owner:

entry P (Owner: Task_id) when True is
begin
   if Caller = Owner then
      In_use := In_use + 1;
   else
      requeue Alien_P with abort;
   end if;
end P;

entry Alien_P (Owner: Task_id) when In_use = 0 is
begin
   Caller := Owner;
   In_use := 1;
end Alien_P;

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de