|
|
Threads-Devel : |
From: William R Speirs (bill.speirs_at_[hidden])
Date: 2008-03-12 22:37:01
Hello-
> Not at all. There are things in the boost library not in the standard
> (interruption, shared_mutex, for example), and it's going to be a
> while before C++0x compilers are common place.
Sweet!
> The read/write mutex has been replaced with boost::shared_mutex which
> works fine.
I've downloaded boost v1.34.1; however, there is no shared_mutex in that
version. I'm guessing that shared_mutex is in a beta version?
I looked around the SourceForge page, and the online CVS without finding
the source files that include a shared_mutex. I also checked out the
source from CVS and couldn't find the shared_mutex code :-( So I'll ask
the basic question, how do I obtain the latest source for boost threads
that includes things like shared_mutex?
> Thanks for the offer of help. There isn't a list of what needs to be
> done anywhere. I'll see if I can think of anything. If you think of
> anything yourself, post here, and do it.
My first thought was that semaphores were missing. After reading FAQ #11
and http://www.mail-archive.com/boost@lists.boost.org/msg07826.html I
know more about semaphores and why there are not in Boost than I ever
wanted to know :-)
My next thought was an additional method for the thread class to expose
the underlying "thread" (bad term, don't know what else to call it). For
example in pthreads it would be pthread_t and in Windows it would be a
HANDLE.
Why do this? To allow users to set specific options or call functions
not exposed by Boost threads (that couldn't be reasonably) for the
underlying thread. I'm thinking of the pthread_attr_* functions for
pthreads and the Get/SetThread* functions in Windows (among others).
This could easily be typedefed for each underlying OS and done via a
simple function: thread_t get_thread().
The problem with this... you could easily have a user creating a thread
via Boost then doing something crazy with that thread via the OS
system/library calls. Basically this would open up a method for the user
to shoot them self in the foot.
With that in mind, and the fact that I think this is valuable (why take
away the niceties of Boost just because I need some "harmless" function
like QueryThreadCycleTime), how do you prevent the user from shoot them
self in the foot?
I would think the first step is to actually NOT provide them with the
pthread_t or HANDLE but rather provide a templated function that simply
provides the underlying thread to a functor.
So I'm imagining the user creating a functor for their particular
function, and then the function simply passing the functor the
underlying thread. It would look something like this with obvious
details missing:
// the user's functor
struct GetStackSize
{
size_t stack_size;
void operator()(thread_t t)
{ pthread_attr_getstacksize(t, &stack_size); }
};
// Boost thread member function
template<typename F>
void foo(F &f_ref)
{ f_ref(_thread); }
// user's call
GetStackSize gss;
my_thread.foo(gss);
Of course the user could still do something bad (like make evil calls
inside the functor) and shoot themselves in the foot.
Do people think this is of any worth? Is there a better way to do this
to ensure the user can't get the underlying thread and call evil
functions using it?
One last comment (sorry for the self-conversation style post), in my
experience programmers don't use libraries where their hands are tied or
they have to jump through hoops to make something happen. If I already
have code that uses QueryThreadCycleTime or pthread_attr_getstacksize
and would simply like to integrate with Boost threads, I'm stuck.
Therefore, I'm going to throw away all the things that are going to help
me (scoped locking, etc) simply because I need 1 or 2 function calls I
can't make otherwise.
> I've also got a new Windows mutex implementation to check in, and code
> for acquiring multiple locks, which needs a proper set of tests.
Where would this be checked into? I wouldn't mind trying to break it for
you :-)
Thanks...
Bill-