 | | | -none- | -none- 2007-08-17 - By Jonathan Wakely
Back
On 16/08/07, Warren Young <mysqlpp@(protected)> wrote:
> Jonathan Wakely wrote:
> >
> > Users sharing Rows between threads already have to ensure
> > the Result object doesn't go out of scope in another thread,
>
> Well, funny you should bring give that example. The template we are
> discussing in this thread was created to solve the single-threaded
> version of the same problem.
The example wasn't picked entirely randomly :-)
In a single-threaded program you don't have to worry about a Row
object being destroyed while another thread uses it. If you are
foolish enough to share Rows between threads, you must ensure no
thread is still using it when it is deleted or goes out of scope. So
those brave people doing this must already synchronise access to
shared Rows (and Results, and Connections ...) and I don't think you
need to do any additional synchronisation.
> This comes up when someone runs a query, gets some Rows, then wants to
> get a new result set without copying the Row data to a new data
> structure just to work around the existing dependency of Row on the
> Result that created it. This is a common need when details of the
> second query depend on the results of the first. This problem is now
> solved; Rows no longer require their creator to outlive them.
I think your RefcountedPointer is a great solution.
> The atomic inc/dec issue brought up by Joseph Artsimovich is all that
> prevents the problem in your example from being solved, too. The
> question is, does it *need* to be solved? Obviously I think the single-
> thread variant of this problem does need to be solved. But in light of
> the bottleneck argument I gave in my response to Joseph, you can guess
> that I'm not seeing the value in solving the multi-thread variant.
I agree. It would be a bad idea to make all operations on Rows
"atomic" (I think the only way would be to acquire a per-Connection
mutex for most operations, which would be useless and expensive in
99.9% of cases, where people don't share objects across threads
anyway)
> So, tell me why I'm wrong. Why is it helpful to send off Rows to a
> second thread while the first reuses the Result object for a new query?
I don't think it is useful, but it's not only that scenario you have
to worry about. Two threads could both call Row::at(int) on Row
objects of the /same/ query result, and there's a race on the memory
allocation in ResUse::field_types(int). You can't prevent that without
unreasonable effort, so users must do their own synchronisation
already. Making RefCountedPointer atomic wouldn't help, and would make
it significantly slower.
> > I think the latest Boost.SharedPtr actually uses a pointer to member
> > data, not member function.
>
> Are you endorsing this difference, or just pointing it out?
Honestly, I don't know the benefits, but if it's good enough for Peter
Dimov (the shared_ptr maintainer and expert) then it's good enough for
me, so I'd copy Boost. Either is better than implicit conversion to
bool :-)
> > With a safe bool there's no need for operator!
>
> Actually, I don't see why it was needed with the existing scheme, but it
> was necessary to make something compile. I don't remember the details.
You're right, it was never needed technically ... but if there's a
portability reason I see no problem with keeping it, as long as it
uses the same logic as the safe bool conversion.
Jon
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsub=mysql@(protected)
|
|
|