[ Not subscribed to -dev, so replying out-of-band from reading web
archives - apologies for formatting foul-ups]
There are two ways about this:
a) either forego on the side effect and resort to a linear (slow)
search/scan when the stack is unsorted (which can happen, for
instance, after an element has been inserted (sk_*_insert())), so that
sk_find() will be threadsafe (assuming no parallel insert()/push()
calls) or
This isn't ideal, obviously
b) provide a threadsafe environment by surrounding a least each sort
with a lock. (I can see why lock-encapsulating the find() would be
bothersome, as it would make threads wait for each other, where they
wouldn't really have to in 99% of cases, so the brute-force approach
of lock-covering the find() shouldn't be contemplated.
You're walking a well worn path WRT race conditions here: if you allow
arbitrary calls to the STACK interface to add and remove items, then all
reads are still susceptible to races (with other threads making
arbitrary modifications) without some form of locking. That adds
overhead for all calls, and if you restrict it entirely within the STACK
API, making it safe is going to be futile anyway:
Thread 1 Thread 2
item = find()
item = find()
free(item)
use(item)
No matter how much locking you put in find(), you're in trouble.
By using the model you are talking about, you're still assuming that
once the sort is done, the STACK is immutable, and that's just a feature
of the particular use of the STACK interface that's in question here.
Which leads to the third option, which is what I was doing with the patch:
c) Require that the user of the STACK interface be aware that *_find()
is only thread safe if the STACK is sorted before there's a possibility
of multiple threads accessing it at the same time
The nomenclature of the _find() operation does leave something to be
desired (both for the fact that it can modify the object it acts on, and
that its worst case performance is worse than the obvious O(n) you'd
expect), but I'm not sure there's anything particularly wrong with the
semantics per se. I'd probably prefer that it failed hard if the stack
wasn't already sorted, but that's just me.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
