Re: How can I avoid Using a Semaphore? (long)

[mark_lundquist@my-deja.com]

Hey Steve,

I'd like to take up your original question: "How can I avoid using a
semaphore?"

In article <cd%76.260429$U46.8278617@news1.sttls1.wa.home.com>,
  "DuckE" <nospam_steved94@home.com> 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/