On 10/01/2011, at 8:30 AM, judy wrote:
> What do you think guys:
> http://code.google.com/p/judyarray/
Ok, had a quick look at source:
typedef struct {
judyslot root[1]; // root of judy array
void **reuse[8]; // reuse judy blocks
JudySeg *seg; // current judy allocator
uint level; // current height of stack
uint max; // max height of stack
JudyStack stack[1]; // current cursor
} Judy;
basically, this data structure holds state information between
calls, and so the system isn't re-entrant. However it's a per-Judy
array structure, so provided distinct threads access distinct arrays
it should be ok.
However, distinct threads SHOULD be able to read a single Judy array
without interference.
This is an age old problem, first becoming critical in the mis-design of SQL
and repeated again and again and again by people that learnt C as a first
programming language and never graduated to learning how to program
properly. (SQL "cursor" concept is screwed).
Generally, if you need any state to do read access to a data
structure, it has to go on the stack, or, be created dynamically and
held by the client, never the data structure. Clearly if you're
modifying a data structure the situation is different, asynchronous
modifications are unprincipled (which means NO you should NOT
lock anything, it's up to the client to do the synchronisation).
Again, I'm not sure from a brief look at the code. Re-entrant code
can sometimes be slower.
Another stupid example of this problem is OpenGL. Another mis-design
which in this case is inexcusable (since it's relative modern).
Microsoft, generally, got this stuff right. Most Unix stuff does not.
--
john skaller
[email protected]
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
