Re: Btree Compare callback function - context parameter

Every thread has its own stack.
Why not use that?  No synchronization required. :)

--Sarge

"Michael Hollins" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Patrick,
> Looks to me like you are reinventing thread local storage (TLS). All the
> platforms that I work on already have TLS, and yes TLS is an approach that
> can be used in this scenario given the absence of any direct support for
> this sort of thing in Berkeley DB.
>
> BTW: There have been a couple of times where I had an idea for an
> "enhancement" for Berkeley DB, but when I thought about it further I
> realised why that "enhancement" had probably already been thought of and
> discarded by the Sleepycat people as innapropriate for one reason or
> another. I suspect the idea of passing app context through put() calls may
> have similarly already been considered and discarded. Having said that, I
> might think about the idea a bit more and post a follow up message on the
> subject.
>
> cheers,
> mick
>
> "Patrick Schaaf" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > "Michael Hollins" <[EMAIL PROTECTED]> writes:
> >
> > >I've been looking for a similar thing to Chad, but I'm a bit confused
> about
> > >how to make use of app_private.
> >
> > >Say I have multiple threads all using the same DB handle to refer to an
> > >opened database. I don't see how I could make use of app_private so
that
> > >information I pass to put() would be delivered to my btCompareFn. The
> > >problem being that threads performing concurrent puts would clobber
each
> > >others' app_private data.
> >
> > Hi Mick,
> >
> > good critique! I usually don't do threads, so it didn't occur to me.
> > In such a multithreaded situation, an extra void* argument to put(),
> > passed on to the comparison function, would be really handy.
> >
> > A possible workaround would be to associate a suitable structure
> > with the DB app_private, something like this:
> >
> > struct app_private_thread_put_stuff {
> > pthread_mutex_t manipulate_this;
> > #define MAX_NR_ACTIVE_THREADS
> > int nr_active_threads;
> > struct {
> > pthread_t thread_id;
> > void *arg;
> > } put_arg[MAX_NR_ACTIVE_THREADS];
> > };
> >
> > Now, make a wrapper for put() which locks app_private->manipulate_this,
> > puts the current thread's pthread_t / putarg into that array, unlocks
> > the app_private->manipulate_this mutex, and then calls the real ->put().
> > The compare function can then scan the put_arg[] array for its
pthread_t,
> > and thus find its own arg. On the way out, after ->put() returns, the
> > put wrapper again locks / removes the info / unlocks.
> >
> > Ugly, certainly a lot of overhead compared to passing an additional
> > argument on stack, but I can't see another way right now. The overhead
> > should still be small compared to the possible advantage of using
> > threads (if it isn't, the use of threads could be misguided in the
> > first place :)
> >
> > best regards
> >   Patrick
>
>