Re: Threading issue in next standard
Jiang wrote:
SuperKoko wrote:
I hope it'll be a library facility.
Languages having builtin threading tend to impose a single very
particular mean to do multithreading and it's easy to reach the limits
of those models.
Maybe this is true. But if this "single very particular mean" helps,
then do we really need the freedom for threading?
For example, compared with
void foo()
{
scoped_lock(mutex); // OK, RAII used here
// access the resource...
}
, the following function bar
void synchronized bar()
{
// access the resource...
}
is much clean and well controlled in my mind.
There are 3 locking issues here:
- A mutex. Covers all situations
- A critical section. Only one thread is allowed to access this thread
at a time
- An atomic section of code. This effectively means that all other
threads must wait while
this block of code is completed. With a genuine dual-processor there
really are 2 threads
running at a time so this may be harder to enforce.
With a mutex, you have different mutexes but the same mutex could be
locked in multiple parts of
the code which clash with each other
Here programmers do not have to remember RAII,
well, if RAII is parts of the language. Compared
with lock/unlock, constructor/destructor is much
reliable, but why not make a futher step?
It's not a matter of programmers "remembering RAII". RAII is there so
that programmers don't
have to remember to release resources.
The problem is, even we have a thread library, lots of
low level details must be handled by our programmers.
Low-level details would be handled by the writers of the standard
libraries rather than by the
compiler manufacturers, who may be different. I would prefer it if my
code were compiled directly
in machine code rather than the compiler having to keep compiling a
standard library of templates
time and again.
Also, if the library were to be written on a UNIX system to wrap
pthreads then would it use a header
file <cpthread> to avoid name-clashing or would the entire pthread
library be automatically "included"
into your source when you weren't actually using it directly. Similarly
on Windows with their standard
library and on any other platform that has multi-threading.
Just consider this, the read_write_mutex in boost.thread
was removed due to problems with deadlocks.
No matter how good a threads library you write, it is up to the
application-level programmer to ensure
that there are no deadlocks. The purpose of a library is to aid good
programming, not to prevent bad
programming. Of course you do put in some protection so that
programmers won't do the wrong thing.
The potential problem of read-write locks is writer starvation. If
there are always readers about, the
writer may never get a chance to write. This can be prevented by adding
an addition mutex - the
reader and writer both must acquire the mutex before acquiring the
read-write lock, but there is a
difference. The read releases the mutex immediately on acquiring it,
the writer holds onto the mutex
until it gets the read-write lock. That means the mutex remains locked
if there is a writer waiting to
write, and new readers cannot read although the existing ones may
continue reading. In practice
this is not a bad thing as although the readers may wait a bit, they
will eventually read the most
updated information.
Now if you have to implement a library on top of what you already have,
then on a POSIX system you
would probably implement read-write locks on top of pthread_rwlock_init
etc. There is, as far as I'm
aware no defined behaviour as to whether writers get priority in such a
library so to be safe you may
well add it in to your own.
If those
best experts can not handle the low level issues
correctly (although it's rare case, of course), IMHO,
I would like to use the single particular, but controllable
one. Freedom here does not benefit too much for me.
The issues with boost is that they are trying to write a library for
all systems, but different systems
do things differently. On Windows there is no concept of rwlock, you
have to implement the whole
thing yourself using just mutex and semaphore etc.
That would be the same for any "standard" library for threads. A
language feature would mean that
your code would be directly compiled to the relevant machine code.
---
[ 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.comeaucomputing.com/csc/faq.html ]