From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-08 12:21:09
--- In boost_at_[hidden], scleary_at_j... wrote:
> > Issues such as re-entrancy (recursion) are an implementation
detail,
> > not actually part of the definition of the term. Same for the
name
> > of the operations available, and to some extent the operations
> > available (for instance, a try_lock is not a requirement by the
> > definition of the term, but is a very useful implementation
detail).
>
> I still disagree. An implementation detail is, by *my* definition
anyway,
> something that can change without requiring end-user code to be
aware of the
> change. For example, run-time parameters can be stored in an .ini
file, the
> Registry, an XML file, or some proprietary format; one can write a
> run_time_parameter class that uses any of these as its underlying
storage,
> and the user code wouldn't care (as long as all the
run_time_parameter
> classes had the same interface).
>
> So end-user code should not *ever* have to care about implementation
> details.
>
> If I design a program framework that assumes it has a re-entrant
mutex, and
> then change the "implementation detail" so that the mutex is no
longer
> re-entrant, then my entire framework becomes full of deadlock
possibilities.
> Therefore, I argue that re-entrancy of a mutex is *not* an
implementation
> detail, but defines two sub-definitions of a general "mutex"
definition.
>
> Similar arguments hold for
> try-locking/timed-try-locking/static-init/who-knows-what-else:).
Each of
> these attributes change how the mutex can be used, not how it
works; and
> therefore introduce new sub-definitions of "mutex", not
implementation
> details.
>
> IMO, of course. :)
>
> -Steve