[boost] Re: Boost::thread feature request: thread priority
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Maxim Egorushkin wrote:
> [...]
> > Seems like the issue is undefined behaviour when casting away volatile.
> > Do I get it right?
>
> Yes, UB is the issue ("one of the most obvious tips of the iceberg").
>
> Well, more on volatiles (low level stuff) can be found below. Uhmm,
> as for "higher level safety" (and also efficiency)... you might want
> to take a look at ADA's "protected types" (and the "proxy model"):
>
> http://groups.google.com/groups?threadm=3D7E18EB.BC80C2EB%40web.de
> http://groups.google.com/groups?threadm=3D7E24FC.E1AE86B0%40web.de
> (Subject: Re: POSIX Threads and Ada)
That was quite instructive. Thank you, Alexander, very much.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
Maxim Egorushkin wrote:
[...]
> Seems like the issue is undefined behaviour when casting away volatile.
> Do I get it right?
Yes, UB is the issue ("one of the most obvious tips of the iceberg").
Well, more on volatiles (low level stuff) can be found below. Uhmm,
as for "higher level safety" (and also efficiency)... you might want
to take a look at ADA's "protected types" (and the "proxy model"):
http://groups.google.com/groups?threadm=3D7E18EB.BC80C2EB%40web.de
http://groups.google.com/groups?threadm=3D7E24FC.E1AE86B0%40web.de
(Subject: Re: POSIX Threads and Ada)
Original Message
Date: Fri, 04 Jul 2003 11:30:56 +0200
Newsgroups: comp.programming.threads
Subject: Re: Does anyone think 'volatile' is a platform-independent
way to make variable access thread safe?
References: ... <[EMAIL PROTECTED]>
Ziv Caspi wrote: ...
Ziv, "volatile" stuff IS brain-damaged. Really. kinda-
Originally, C/C++ volatiles were indeed designed having memory mapped
I/O ("registers"/"ports") in mind. At that time hardware was rather
simplistic and didn't do any reordering in either "ordinal" or "I/O"
space. Modern hardware COULD reorder memory accesses in ALL spaces.
So, you basically need almost the same reordering constrains (see the
links below) for portable device driver programming as for threading.
The situation is actually kinda more complicated because for device
drivers you'd need to "control" BOTH spaces -- e.g. if you publish a
bunch of structure addresses and those structure meant to be
read/write by a device, you'll need to ensure "cross-space" ordering.
Unfortunately, the upcoming and still lacks
facilities (ala "msync" stuff -- pls see below) to do that... unless
they really want to impose "total ordering" if you use any read/write
IO calls.
Later, volatiles were kinda {re-}used for setjmp/longjmp stuff in
order to spill the locals to memory (and to reload them after the
jump). Finally, volatiles are also needed for static sig_atomic_t's.
Both these uses of volatiles are purely "single-threaded". Ideally,
we should get rid completely of setjmp/longjmp (ISO C should adopt
C++ exceptions... but after they will be repaired, of course) and
also asynchronous signals (threads shall replace them). Given the
upcoming and , C/C++ volatiles could then be
deprecated as well. Now, back to threading and C++... here's some
C++ code for "curious" folks who can "speak C++":
http://www.terekhov.de/pthread_refcount_t/experimental/refcount.cpp
Some wording about msync "semantics" can be found here:
http://www.google.com/groups?selm=3EE0CA46.593F938B%40web.de
(Subject: Re: Asynchronous queue without synchronization primitives)
Reference counting operation are described here:
http://www.terekhov.de/pthread_refcount_t/draft-edits.txt
Comments are quite welcome. TIA.
regards,
alexander.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > http://google.com/groups?selm=3f01e07b%40usenet01.boi.hp.com > (Subject: Re: Does anyone think 'volatile' is a platform-independent > way to make variable access thread safe?) > > Check out this entire thread. Follow the links. ;-) Thank you, Alexander, for the links. Seems like the issue is undefined behaviour when casting away volatile. Do I get it right? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
Maxim Egorushkin wrote: > > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > > Maxim Egorushkin wrote: > > > > > > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message > > > news:[EMAIL PROTECTED] > > > > > > > > Maxim Egorushkin wrote: > > > > > > > > [... "ala Alexandrescu" volatiles ...] > > > > > > > > http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de > > > > http://groups.google.com/groups?threadm=3EE861E5.13B60F31%40web.de > > > > (Subject: Re: volatile keyword usage philosophy (long!)) > > > > > > Sorry, I failed to figure out the point in that topics. > > > > That's okay. > > But I'd love to :). Is the Alexandrescu's idea of using volatile keyword for > designating thread safe member functions somewhat "brain damaged"? "Yeah, exactly." http://google.com/groups?selm=3f01e07b%40usenet01.boi.hp.com (Subject: Re: Does anyone think 'volatile' is a platform-independent way to make variable access thread safe?) Check out this entire thread. Follow the links. ;-) regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Maxim Egorushkin wrote: > > > > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > > > > Maxim Egorushkin wrote: > > > > > > [... "ala Alexandrescu" volatiles ...] > > > > > > http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de > > > http://groups.google.com/groups?threadm=3EE861E5.13B60F31%40web.de > > > (Subject: Re: volatile keyword usage philosophy (long!)) > > > > Sorry, I failed to figure out the point in that topics. > > That's okay. But I'd love to :). Is the Alexandrescu's idea of using volatile keyword for designating thread safe member functions somewhat "brain damaged"? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
Maxim Egorushkin wrote: > > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > > Maxim Egorushkin wrote: > > > > [... "ala Alexandrescu" volatiles ...] > > > > http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de > > http://groups.google.com/groups?threadm=3EE861E5.13B60F31%40web.de > > (Subject: Re: volatile keyword usage philosophy (long!)) > > Sorry, I failed to figure out the point in that topics. That's okay. regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Maxim Egorushkin wrote: > > [... "ala Alexandrescu" volatiles ...] > > http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de > http://groups.google.com/groups?threadm=3EE861E5.13B60F31%40web.de > (Subject: Re: volatile keyword usage philosophy (long!)) Sorry, I failed to figure out the point in that topics. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
Maxim Egorushkin wrote: [... "ala Alexandrescu" volatiles ...] http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de http://groups.google.com/groups?threadm=3EE861E5.13B60F31%40web.de (Subject: Re: volatile keyword usage philosophy (long!)) regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost::thread feature request: thread priority
Maxim Egorushkin said:
>
> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> Priorities are implemented, but still undergoing design changes, in
>> the thread_dev branch. The timer, if I understand what you want, is
>> trivial to implement portably with the current Boost.Threads
>> interfaces, but I do plan on addressing this as well.
>
> Speaking about the timer I ment something like that:
>
> typedef int milliseconds;
>
> class stopwatch
> {
> public:
> stopwatch()
> : started_(::GetTickCount())
> {}
>
> milliseconds elapsed() const
> {
> return ::GetTickCount() - started_;
> }
>
> private:
> const DWORD started_;
> };
Ahh... that's not a threading concept ;).
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Priorities are implemented, but still undergoing design changes, in the
> thread_dev branch. The timer, if I understand what you want, is trivial
> to implement portably with the current Boost.Threads interfaces, but I do
> plan on addressing this as well.
Speaking about the timer I ment something like that:
typedef int milliseconds;
class stopwatch
{
public:
stopwatch()
: started_(::GetTickCount())
{}
milliseconds elapsed() const
{
return ::GetTickCount() - started_;
}
private:
const DWORD started_;
};
>
> > I'm aware of the fact that it's very operating system specific. But I do
> > think that it could be done with elegance and ease in the spirit the
> > whole library adhere. The first thing to come in mind is to add a couple
> > of member functions to boost::thread like this:
> >
> > class thread
> >
> > {
> >
> > // ...
> >
> > void increase_priority();
> >
> > void decrease_priority();
>
> Not that useful, IMO. Usually you want to set a specific priority, and
> this interface would require several calls to do so. Further, these calls
> can fail, so should probably have bool return types.
Agree.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
Look at the thread_dev branch of boost::thread in the CVS. There are many changes (including priority) that haven't been finalised yet. Hopefully they will make it into 1.31.0 whenever that will be released. Cheers Russell Maxim Egorushkin wrote: Hello, I've been missing a feature in the thread library: managing a thread priority. And, BTW, the class encapsulating stopwatch functionality with a millisecond precision would be very useful. It would help writing more portable programs (as boost::thread is portable). ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
