RE: [boost] RFC: Multithreading design constraints

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-06-08 11:27:08

> -----Original Message-----
> From: Beman Dawes [mailto:beman_at_[hidden]]
> Sent: Thursday, June 08, 2000 9:58 AM
> To: boost_at_[hidden]; boost_at_[hidden]
> Subject: Re: [boost] RFC: Multithreading design constraints
> 
...
> 
> Can we assume a compiler (which may be multi-platform, like
> Metrowerks or egcs) treats operating system function calls like
> "library I/O functions"?  That seems risky.  Volatile seems a safer
> way to force sequence, at least based on that one sentence in the
> standard.

Isn't all this talk about library calls/system calls/volatile getting us a
bit sidetracked?  

I thought that we were trying to come up with the abstract behavior of the
synchronization primitives, not a concrete realization.  Isn't it sufficient
at this point to come up with requirements like, "A guard shall lock the
mutex at the point of construction and release it at the point of
destruction."  If we all agree that the requirement *can* be fulfilled, then
why argue about the specifics of *how* it will be done.  It seems this level
of specificity is best left to the library implementor(s), who can take
different approaches if necessary to solve the problem depending upon the
quirks of the platform/compiler.