Topic: Threads/locking [Was: The future of C++]
Author: unoriginal_username@yahoo.com (Le Chaud Lapin)
Date: Tue, 27 Apr 2004 04:32:15 +0000 (UTC) Raw View
Hi.
nagle@animats.com (John Nagle) wrote in message news:<NqAhc.53906>
> But if the compiler is going to help with locking, language
> support is needed.
Why?
> Some things only the compiler can do:
>
> - generate direct locking instructions inline when
> appropriate.
> - lock at every entry to an object from the outside
> - optimize out unneeded locks
> - Calls to a public function from inside an
> object may not need a relock.
> - access functions that retrieve a single
> value using an atomic machine operation
> may not need locking. (Yes, you have
> to check for the case where a value is
> updated twice within a member function, offering
> the possibility of a transient value.)
> - Functions that don't access member data or functions
> don't need locking.
Again, why? By locking, do you mean bus locking, spin locks, or
mutex-type locks. I am thinking you mean mutex type locks. If so,
certainly you are aware that there is some non-trivial overhead
involved in performing the lock.
Is it so hard to make a portable mutex class and call ::lock() and
::unlock()?
-Chaud Lapin-
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: davideng2004@yahoo.com (David Eng)
Date: Thu, 22 Apr 2004 20:56:20 +0000 (UTC) Raw View
nagle@animats.com (John Nagle) wrote in message news:<NqAhc.53906$Nn7.33879@newssvr25.news.prodigy.com>...
> If you think of threads in terms of a library, that's not
> a matter for C++ standardization. We already have POSIX threads,
> which are available across multiple platforms.
>
> But if the compiler is going to help with locking, language
> support is needed.
>
> Some things only the compiler can do:
>
> - generate direct locking instructions inline when
> appropriate.
> - lock at every entry to an object from the outside
> - optimize out unneeded locks
> - Calls to a public function from inside an
> object may not need a relock.
> - access functions that retrieve a single
> value using an atomic machine operation
> may not need locking. (Yes, you have
> to check for the case where a value is
> updated twice within a member function, offering
> the possibility of a transient value.)
> - Functions that don't access member data or functions
> don't need locking.
>
> So there's a real payoff to making the compiler knowledgeable about
> locking.
>
> John Nagle
> Animats
That what I mean. Compilers shall handle the synchronous primitives.
Puting a library into C++ standard have two purposes. First, if
compilers can generate better code, the compilers shall do it.
Second, the compilers shall enforce error checking. If it is just a
thread library, it will put all responsibility to developers. The
developers have to make correct library calls. BTW, pthread is C
based and only for Unix platform. In a distributed environment, we
need an object mode for distributed computing. That's why C++ thread
mode is needed in the C++ standard.
David Eng
> David Eng wrote:
> > Thomas Richter <thor@cleopatra.math.tu-berlin.de> wrote in message news:<c607kn$q19$2@mamenchi.zrz.TU-Berlin.DE>...
> > > I also feel that CORBA does its job possibly only half the way it could.
> > > For example, it nicely runs new threads for me serving my objects, but
> > > at the same time it doesn't provide necessary services for keeping
> > > object states consistent amongst the threads - there are no "mutex"
> > > specifications in CORBA.
> >
> > I blame this for C++. The thread mode should be built into C++
> > instead of CORBA. I still cannot understand why C++ doesn't have a
> > standard thread library. We are moving to grid computing, yet C++
> > committee doesn't think it is important to standardize a thread
> > library. The another area bothers me is database access layer. All
> > these database vendors promote JDBC because there is no a standard C++
> > access library. If these vendors stop to support their proprietary
> > C++ API, who will use C++ in a distributed environment? I never head
> > C++ committee even has an initiative to standardize a database access
> > layer library. No matter how great C++ is, without a standard thread
> > and data access libraries, C++ will have a hard time to survive in a
> > distributed computing. Just to imagine how C++ can survive in a
> > system computing without an I/O library! If the committee thinks
> > proprietary libraries can do the job, I am sure that C++ will not be a
> > mainstream programming language; it will downgrade to a third class
> > language doing some limited applications.
>
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Fri, 23 Apr 2004 23:09:27 +0000 (UTC) Raw View
I'm less concerned about the library issue than the
language issue. Even if a standard thread library is
provided for C++, many projects will continue to use POSIX
or platform-specific thread primitives.
Locking, though, really is a core language-level issue.
As discussed below, there are some things only the compiler
can do well in this area.
Is somebody addressing this?
John Nagle
Animats
David Eng wrote:
> nagle@animats.com (John Nagle) wrote in message news:<NqAhc.53906$Nn7.33879@newssvr25.news.prodigy.com>...
>
>>If you think of threads in terms of a library, that's not
>>a matter for C++ standardization. We already have POSIX threads,
>>which are available across multiple platforms.
>>
>> But if the compiler is going to help with locking, language
>>support is needed.
>>
>> Some things only the compiler can do:
>>
>> - generate direct locking instructions inline when
>> appropriate.
>> - lock at every entry to an object from the outside
>> - optimize out unneeded locks
>> - Calls to a public function from inside an
>> object may not need a relock.
>> - access functions that retrieve a single
>> value using an atomic machine operation
>> may not need locking. (Yes, you have
>> to check for the case where a value is
>> updated twice within a member function, offering
>> the possibility of a transient value.)
>> - Functions that don't access member data or functions
>> don't need locking.
>>
>>So there's a real payoff to making the compiler knowledgeable about
>>locking.
>>
>> John Nagle
>> Animats
>
>
> That what I mean. Compilers shall handle the synchronous primitives.
> Puting a library into C++ standard have two purposes. First, if
> compilers can generate better code, the compilers shall do it.
> Second, the compilers shall enforce error checking. If it is just a
> thread library, it will put all responsibility to developers. The
> developers have to make correct library calls. BTW, pthread is C
> based and only for Unix platform. In a distributed environment, we
> need an object mode for distributed computing. That's why C++ thread
> mode is needed in the C++ standard.
>
> David Eng
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Wed, 21 Apr 2004 20:55:58 +0000 (UTC) Raw View
If you think of threads in terms of a library, that's not
a matter for C++ standardization. We already have POSIX threads,
which are available across multiple platforms.
But if the compiler is going to help with locking, language
support is needed.
Some things only the compiler can do:
- generate direct locking instructions inline when
appropriate.
- lock at every entry to an object from the outside
- optimize out unneeded locks
- Calls to a public function from inside an
object may not need a relock.
- access functions that retrieve a single
value using an atomic machine operation
may not need locking. (Yes, you have
to check for the case where a value is
updated twice within a member function, offering
the possibility of a transient value.)
- Functions that don't access member data or functions
don't need locking.
So there's a real payoff to making the compiler knowledgeable about
locking.
John Nagle
Animats
David Eng wrote:
> Thomas Richter <thor@cleopatra.math.tu-berlin.de> wrote in message news:<c607kn$q19$2@mamenchi.zrz.TU-Berlin.DE>...
> > I also feel that CORBA does its job possibly only half the way it could.
> > For example, it nicely runs new threads for me serving my objects, but
> > at the same time it doesn't provide necessary services for keeping
> > object states consistent amongst the threads - there are no "mutex"
> > specifications in CORBA.
>
> I blame this for C++. The thread mode should be built into C++
> instead of CORBA. I still cannot understand why C++ doesn't have a
> standard thread library. We are moving to grid computing, yet C++
> committee doesn't think it is important to standardize a thread
> library. The another area bothers me is database access layer. All
> these database vendors promote JDBC because there is no a standard C++
> access library. If these vendors stop to support their proprietary
> C++ API, who will use C++ in a distributed environment? I never head
> C++ committee even has an initiative to standardize a database access
> layer library. No matter how great C++ is, without a standard thread
> and data access libraries, C++ will have a hard time to survive in a
> distributed computing. Just to imagine how C++ can survive in a
> system computing without an I/O library! If the committee thinks
> proprietary libraries can do the job, I am sure that C++ will not be a
> mainstream programming language; it will downgrade to a third class
> language doing some limited applications.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]