Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2002-03-25 22:57:57


I am sorry a correction to my previous
reply. This corretion doesn't
change the conclusion.

---- CORRECTION ---
the overhead can be estimated as X*log(N), where
N is the average number of objects in
the system at any give time (the objects
that are controlled with shared_pointer<>),
and X is the average number construction/destruction
calls of the shared_pointer<> class per second.

----
--- "Richard Damon (E-mail)"
<RDamon_at_[hidden]> wrote:
> I assume that the implementation of foo is what is
> starting the second
> thread.
> 
> You seem to have a serious asymmetry in your
> specification. C code is
> expected to manage the lifetime of the object, but
> you want C++ code to not
> need to manage it. You are requiring the interface
> to be C based and not
> allowed to know the type of caller. Your are asking
> foo to possibly manage a
> resource that it does not know the source of. C code
> created it with malloc,
> C++ code created it with new. You C++ example is
> violating the specs of the
> Boost shared_ptr as the shared_ptr does not have
> total ownership of the
> object. The definition of Boost's shared pointer
> does not allow for your
> style of shared ownership.
> 
> I see your choices as the following:
> 
> 1) Keep consistent ownership rules. Since the
> existing C interface has
> caller ownership, the C++ needs the same. This means
> that if you are to use
> shared_ptr you can not let it go out of scope until
> after you have confirmed
> that foo is done. (This does not meet your
> requirement 4 which seems flawed)
> 
> 2) You need a much smarter shared_ptr that can
> reconnect to other copies
> from the stored pointer, and if there is none to
> remember that it does not
> own it. A normal shared_ptr will not be smart enough
> to do this due to the
> overhead that will be added, as it requires the
> keeping of a map of some
> sort of values under controlled by all shared_ptrs
> in the program.
> 
> 3) You need to eliminate condition 1. Since foo is
> starting another thread,
> it is really just a wrapper to a client. It should
> not be a problem to have
> two separate wrappers to model the two distinct
> object ownership rules. You
> could have a
> 
> void the_real_foo(int*, shared_ptr<int>) {
> ... the original code, when you create a separate
> thread pass the shared_ptr
> to it to keep the object alive
> }
> 
> void foo(int* p){
> 	shared_ptr<int> sp;	/* a dummy since C callers keep
> ownership */
> 	the_real_foo(p, sp);
> }
> 
> void foo(shared_ptr<int> sp) {
> 	the_real_foo(sp.get(), sp);
> }
> 
> 4) You fire the designer who gave the impossible
> specs.
> 
> > -----Original Message-----
> > From: boost-admin_at_[hidden]
> > [mailto:boost-admin_at_[hidden]]On
> > Behalf Of E. Gladyshev
> > Sent: Monday, March 25, 2002 4:38 PM
> > To: boost_at_[hidden]
> > Subject: [boost] smart pointer puzzle
> >
> >
> >
> > I've decided to start another thread,
> > since my original "plain pointers and shared_ptr"
> > caused some confusion.
> >
> > To understand what I was talking about,
> > here is a puzzle :).
> >
> > Objective:
> >    implement a smart pointer
> >    shared_pointer<int> and function foo( int* px )
> >    that does something on *px.  foo() can
> >    use shared_pointer<int> but only internally.
> >
> > Requirements:
> > 1. There must be only one version of foo() without
> >    any conditional compiling.
> >
> > 2. The foo() client and foo() can be running
> >    in different threads.
> >
> > 3. It should be obvious how to implement
> > shared_pointer<int>
> >    in multi-thread environment.
> >
> > 4. foo() has to work correctly if the client uses
> >    shared_pointer<int> to share the 'px' object.
> >    In other words, if shared_pointer<int> goes out
> >    of scope on the client side while foo() is
> still
> >    using the object pointed by 'px' (can happen 
> in
> > multi-thread
> >    applications), the program should not crash.
> >    foo() has to call the object destructor when
> >    it exits and nobody else references the object.
> >
> > 5. foo() has to work consistently if the client
> >    is not using shared_pointer<int> ( a legacy
> >    C-code).
> >
> > 6. Following solutions are not accepted.
> >     - Solution 1. it is not possible.
> >     - Solution 2. change the foo() interface.
> >     - Solution 3. create multiple versions of
> foo().
> >
> >
> > Here are some foo() usages:
> >
> > main()
> > {
> >    {
> >       shared_pointer<int> x( new int );
> >       foo( x.get() );
> >       //make sure that foo() is started
> >       ...
> >    } //forget about 'x' here
> >
> >    //do something else
> >    ...
> >
> >    //make sure that foo() is done.
> >    ...
> >    return 0;
> > }
> >
> > main()
> > {
> >    int x;
> >    foo( &x );
> >    //wait when foo() is done.
> > }
> >
> > main()
> > {
> >     int *px = new x;
> >     foo( px );
> >
> >     //wait when foo() is done.
> >     delete px;
> > }
> >
> >
> > See a proposed solution in my first
> > "plain pointers and shared_ptr" message.
> >
> > Anybody has a better idea?
> >
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk