hattons@globalsymmetry.com ("Steven T. Hatton") writes:

> Hyman Rosen wrote:
>
> > John Nagle wrote:
>
> > ...Java programmers who have been using nested classes for years.
>
> That is correct.  Java supports inner classes, and they are sometimes

C++ not? In C++ there are too nested (inner) Classes possible.

[Threads]

> I'm not sure which part would be useless and hard to specify.  If I
> understand the motivation, it is to have element level locking in a
> collection, as well as collection level locking.  This sounds useful to me.
> And I'm really not sure that there's a problem implementing it.  I may not
> understand the subtelties implied.

Here too I don't understand the diskusion about threads, sorry, this ist
not ment in a angry way!
Boost supports Thread for Linux, Windows and MacOS. Why not use a free
library for this things, an let the language be language?
The only Problem is the standard library, which is not thread save,
there has to be something son, I think.

Kind regards,
Nicolas


--
|     Nicolas Pavlidis       |       Elvis Presly:    |\ |__      |
|   Student of SE  & KM      |      "Into the goto"   | \|__|     |
|  pavnic@sbox.tugraz.at     |       ICQ #320057056      |        |
|-------------------University of Technology, Graz----------------|

---
[ 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                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<1080589480.156136@master.nyc.kbcfp.com>...
> Steven T. Hatton wrote:
> > I'm not sure which part would be useless and hard to specify.
>
> I think it would be hard to specify what data is locked by a lock,
> and what that would mean. I think it would be useless because the
> things that need locking are defined by the application, and are
> seldom "one object" or "one container".
>

Hyman Rosen has hit the nail exactly on the head here, and pointed out
the most significant issue in adding locking support to C++:  In the
general case, only the application can know exactly what needs to be
locked and when.

Obviously there are some places where locking can be defined without
regard to the specific application.  For example, new and delete come
to mind since they can be made thread-safe by appropriately locking
their internal data structures invisibly to the application.  Some
simple data structures, such as a queue, can also be made thread-safe
due to their limited interface.

Any data structure that supports modification via iteration, however,
cannot be made thread-safe at the library level.  Only the application
can define what thread-safe means and apply the appropriate locking
mechanisms over the correct intervals.

My hope is that thread and locking support will be added to C++ in
such a way as to maintain the freedom of the application to determine
correct locking policies for thread-safety.

Randy.

---
[ 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                       ]

   It's easy enough to define what data is locked by a lock.
The question is whether locking by object is too restrictive.

   What's the history of per-object locking in other languages?
When does it lead to trouble?

    John Nagle
    Animats

Hyman Rosen wrote:
> Steven T. Hatton wrote:
>
>> I'm not sure which part would be useless and hard to specify.
>
>
> I think it would be hard to specify what data is locked by a lock,
> and what that would mean. I think it would be useless because the
> things that need locking are defined by the application, and are
> seldom "one object" or "one container".

---
[ 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                       ]

nagle@animats.com (John Nagle) wrote in news:kOiac.16645$vU7.7765
@newssvr27.news.prodigy.com:

>    It's easy enough to define what data is locked by a lock.
> The question is whether locking by object is too restrictive.

Since you are free to define your objects as granular or course as you
want, I don't see why. Indeed, you can introduce new objects precisely for
the purpose of supporting a particular synchronization requirement. One
thing that might help is language support for forwarding.

In any event, if the locking support is not what you want, you could
continue to use external libraries. Meanwhile, for the 95% of the
applications where the built-in support would suffice, it would be awfully
nice not to have to switch mental threading models (ACE, boost, pthreads,
Win32 threads, home-grown, etc.) for each new project I am working on.

Gregg

---
[ 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                       ]

In article <8c8b368d.0403300631.7269bf6c@posting.google.com>,
rmaddox@isicns.com (Randy Maddox) wrote:

>hyrosen@mail.com (Hyman Rosen) wrote in message
news:<1080589480.156136@master.nyc.kbcfp.com>...
>> I think it would be hard to specify what data is locked by a lock,
>> and what that would mean. I think it would be useless because the
>> things that need locking are defined by the application, and are
>> seldom "one object" or "one container".
..
>Hyman Rosen has hit the nail exactly on the head here, and pointed out
>the most significant issue in adding locking support to C++:  In the
>general case, only the application can know exactly what needs to be
>locked and when.

As this is somewhat abstract, I will give an example; perhaps you can give
some more:

Suppose one have a database of money accounts, where the total amount of
money held by the database must be known at all times. Suppose a
transaction takes place making use of two threadsafe operations: withdraw
amount x, and deposit amount x. If a transaction between two accounts
takes place by first withdrawing amount x from the first account and then
depositing amount x in the second, then the total operation is not
threadsafe in the time between these two operations. So the database must
make sure to lock all access, also read access, between these two
operations.

Thus, a library made up by threadsafe operations (in the example, the
withdraw and deposit operations) could easily be used to construct
non-threadsafe operations (in the example, account transaction) because of
the semantics one wants to capture (in the example, the total sum of the
accounts).

The way out of this dilemma is simple: One should be able to construct a
class "database", and it should supply operations which are considered
threadsafe. It is though simply a semantics that one wants to capture,
which needs not be controllable by the compiler.

  Hans Aberg

---
[ 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                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:kOiac.16645$vU7.7765@newssvr27.news.prodigy.com...
>    It's easy enough to define what data is locked by a lock.
> The question is whether locking by object is too restrictive.
>
>    What's the history of per-object locking in other languages?
> When does it lead to trouble?
>

Well, exclusive per-object locking can lead to huge performance
penalties. SQL92, for example, defines 4 isolation levels (dirty reads,
read committed, repeatable read and serializable) to provide some
flexibility in this matter.




---
[ 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                       ]

>    In C++, you can nest classes, so you can create finer-grained locking
> at need.  Java doesn't support nested classes.

yes it does.

br

Thorsten


---
[ 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                       ]

John Nagle wrote:
>   In C++, you can nest classes, so you can create finer-grained locking
> at need.  Java doesn't support nested classes.

I'm sure that will come as a surprise to Java programmers
who have been using nested classes for years. I guess they'll
have to stop now.

> Java, Ada, and the Modula family do tie locks to data at
 > declaration time

I don't know about Modula, but you are wrong about Java and
Ada. Java's synchronized methods do lock against their object
or class, but Java also allows synchronized to use any object
at all as the lock. And just because soemthing is used as the
lock doesn't prevent the code from accessing any other data.
Ada95 added the idea of protected objects which encapsulate
locking and data, but it has always had tasks with a mechanism
called a rendezvous for intertask communication, and that does
not tie locking to data either.

> Something like this is appropriate to those "do we lock the
> collection, or the elements of the collection" situations.
>    I'd like to see a solution that makes it explicit which
> lock controls which data.

I think this would be generally useless, as well as hard ro
specify.

---
[ 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                       ]

Hyman Rosen wrote:

> John Nagle wrote:

> ...Java programmers who have been using nested classes for years.

That is correct.  Java supports inner classes, and they are sometimes
useful. Java's thread support is also seemingly well designed.  Having very
little hands on experience with other MT support, I dare not draw
comparisons.

>> Something like this is appropriate to those "do we lock the
>> collection, or the elements of the collection" situations.
>>    I'd like to see a solution that makes it explicit which
>> lock controls which data.
>
> I think this would be generally useless, as well as hard ro
> specify.

I'm not sure which part would be useless and hard to specify.  If I
understand the motivation, it is to have element level locking in a
collection, as well as collection level locking.  This sounds useful to me.
And I'm really not sure that there's a problem implementing it.  I may not
understand the subtelties implied.

Can either of you clarify what is meant by "those 'do we lock the
collection, or the elements of the collection' situations."

--
STH

---
[ 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                       ]

John Nagle wrote:
[...]
>> 5.  Automatic class locking
>>
>>> Like "synchronized" classes in Java.  Only one thread can be
>>> "inside" an object at a time.  Lock upon entry to a public
>>> function, unlock at exit.
>
>> It needs to be better than Java's "synchronized" in order to allow a
>> single
>> member function to be locked and not an entire object as Java does,
>> which is
>> crude.
 >
 > [...]
 >
>    I'd like to see a solution that makes it explicit which
> lock controls which data.  The solutions should provide
> enough flexibility that programmers are not tempted to lie
> to the compiler.

In my experience, C++ is flexible enough to allow anybody to craft a
solution that exactly fits the needs. I do not like the Java way since
it is exactly not very flexible, and I think the programmer should
always be in control. But probably there are several related issues here.

I assume that everybody with a little C++ experience will agree that the
language is powerful and flexible enough allow everybody to hand-craft a
solution to the locking that exactly fits his or her needs with respect
to all relevant questions.

Building a mechanism into the language might be a good idea, however I
would like to put forth the opinion that a solution should not be
water-tight, i.e. absolutely safe under all circumstances, because
typically (at least what I have seen so far) any water-tight solution
will be either too restrictive, or have too much overhead.

For me, one of the greatest strengths of C++ is the possibility to
control every aspect of a class's behaviour, and therefore I do not
require explicit language support to create a solution, in this case for
how to perform locking, myself that behaves as if it were part of the
language.

The other side of the coin is that everybody has to invent his own
solution, and I assume that is the motivation for proposing language
level support in the first place, that is to "solve the problem once and
for everybody". However, in light of what I outlined above I would vote
for a library-based approach, since this stays true to keeping the core
language as "simple" and basic as possible and making additional
features flexible, optional components of the language.

Regards, Colin

---
[ 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                       ]

Steven T. Hatton wrote:
> I'm not sure which part would be useless and hard to specify.

I think it would be hard to specify what data is locked by a lock,
and what that would mean. I think it would be useless because the
things that need locking are defined by the application, and are
seldom "one object" or "one container".

---
[ 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                       ]

Edward Diener wrote:
> John Nagle wrote:

>5.  Automatic class locking
>>
>>     Like "synchronized" classes in Java.  Only one thread can be
>> "inside" an object at a time.  Lock upon entry to a public
>> function, unlock at exit.

> It needs to be better than Java's "synchronized" in order to allow a single
> member function to be locked and not an entire object as Java does, which is
> crude.

   In C++, you can nest classes, so you can create finer-grained locking
at need.  Java doesn't support nested classes.

> Again I believe that the next version of C++ is considering the
> threading issue, but members of the C++ standard committee will know about
> that, and hopefully will comment.

    What is going on in that area?  Is there a draft proposal one
can read?

    The fundamental question about theading is whether the
language ties locks to the data being locked.  For historical
reasons, C and C++ haven't done this.  Java, Ada, and the Modula
family do tie locks to data at declaration time - the compiler
(and the reader of the code) can tell which data is protected
by which lock.  This tends to result in far fewer race conditions,
but increases the risk of deadlock.

    Java, Ada, and Modula have been criticized as being too
inflexible in this area.  In Java, each object has
its own private lock.  That can be too restrictive.  If a
class could specify that its lock lives elsewhere, outside the object,
then fewer locks of larger scope become possible.
Something like this is appropriate to those "do we lock the
collection, or the elements of the collection" situations.

    I'd like to see a solution that makes it explicit which
lock controls which data.  The solutions should provide
enough flexibility that programmers are not tempted to lie
to the compiler.

    John Nagle
    Animats

---
[ 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                       ]