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.7 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6f69b1cf0f02b9ac X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-22 09:00:18 PST Path: supernews.google.com!sn-xit-02!supernews.com!sienna.impulse.net!63.208.208.143.MISMATCH!feed2.onemain.com!feed1.onemain.com!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: mark_lundquist@my-deja.com Newsgroups: comp.lang.ada Subject: Re: How can I avoid Using a Semaphore? (long) Date: Mon, 22 Jan 2001 16:51:46 GMT Organization: Deja.com Message-ID: <94hoeu$puk$1@nnrp1.deja.com> References: NNTP-Posting-Host: 130.213.203.87 X-Article-Creation-Date: Mon Jan 22 16:51:46 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Http-Proxy: 1.1 x68.deja.com:80 (Squid/1.1.22) for client 130.213.203.87 X-MyDeja-Info: XMYDJUIDmark_lundquist Xref: supernews.google.com comp.lang.ada:4320 Date: 2001-01-22T16:51:46+00:00 List-Id: Hey Steve, I'd like to take up your original question: "How can I avoid using a semaphore?" In article , "DuckE" wrote: > > To avoid memory leaks I am using a controlled type with reference counting > to implement my data buffer. Since multiple threads may simultaneously have > access to the buffer, I use a protected type for reference counting. > > Since I am using a protected type for reference counting, I cannot assign > packets within a protected type (to implement queue's of packets for > instance) since these assignments would be attempting to do a protected > operation within a protected type. I don't get it! Can you explain that? Are you talking about the "potentially blocking" rule? I don't see how the scenario you described would run afoul of that rule, and I couldn't find anything in your example code to help me understand what you meant... > > I have worked around this using a semaphore (the semaphore is created using > a protected type) around the assignment of packets: > > lock semaphore > assign packet > unlock semaphore I didn't see anything like that in your example -- it looked like you were using your Mutex type (or aMutex or whatever) to protect your free block lists. So help me understand more about this semaphore problem... In the meantime, a couple of notes: 1) You've said you want to avoid heap allocation -- is that for performance reasons? If so, do you know for sure that heap allocation is going to cause you to miss deadlines or cause a performance bottleneck? If you don't know for sure, you might just go ahead and write it using heap allocation and without all this extra complexity. Then, if that turns out to be not good enough, you can always implement your own allocation scheme (and the right way to encapsulate that is probably with your own Storage_Pool type -- it's easy and direct, no "magic" to worry about). 2) Also if you care about performance, implementing a mutex as a protected record is generally a case of "abstraction inversion" with an attendant performance penalty -- my guess is that that's going to hit you harder than heap allocation would. The Ada runtime is implementing protected records on top of mutexes and condition variables and stuff provided by the OS, and it's probably doing all kinds of checks for pending aborts and other stuff that it has to do, and all you want is a mutex! You might look into using the OS-supplied mutexes directly, *if* it turns out that's what you really need (needing locking to be primitive is often a red flag that some part of the design is "inside out"). 3) You have an array of free block lists, and a "parallel" array of mutexes associated with the free block lists. Doesn't that mean that you really want a mutex to be part of a free block list? 4) Just a style point here, but to me using Interfaces.C.Char to represent a byte or octet or whatever you want to call it, seems a little weird. I like to think that Interfaces.C is for interfacing to C. A better choice might be Interfaces.Unsigned_8. Anyway, hope you give some more detail about the semaphore issue... Best Regards, Mark Lundquist P.S. Your identifier style sucks. (Why mince words? :-) :-) :-) Sent via Deja.com http://www.deja.com/