Re: How to avoid unreferenced objects (mutexes etc)

[Darren New <dnew@san.rr.com>]

Matthew Heaney wrote:
> Yes, it does, but you shouldn't bother using it.  Have the task wait on a
> guarded entry of a protected object, and communicate with the task by
> calling a protected procedure of the protected object.

I must admit that I'm not 100% clear on how this is better than a
selective accept, given that a selective accept allows me to time out
and to pick whichever entry is available first. I don't think I can pick
whichever protected object guard opens first, can I?

> Don't use selective accepts in tasks.  This is old-fashioned.  Rewrite your
> tasks to make blocking calls to an internal protected object.  Have
> operations communicate with the task by calling the protected object, which
> wakes up the waiting task.

Which is basically what I did. Except there were about 20 or 30 entry
points, with various combinations or acceptabilities - i.e., only some
operations made sense in some states. There was also a requirement to
wait for events from other sources (e.g., events from the UI or events
from the I/O framework). So I wound up with protected entries that
waited for this or that or the other, then told you which, which you
then called.... anyway, it was an awful mess compared to what it could
have been had I been able to have multiple task bodies defined for a
single task type.

But thanks for the advice. If I ever go back to developing this, I'll
rethink it again.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  The opposite of always is sometimes.
   The opposite of never is sometimes.