oh! i see~ it's a really useful trick. thank you, James
btw, _Locking for MT_, is vmem's internal lock schema expensive? compared with a single global mutex assigned with the 'cur_value' . Regards, TJ 2007/9/5, James Carlson <[EMAIL PROTECTED]>: > > 陶捷 TaoJie writes: > > In dtrace.c, function dtrace_probe_create(), there're a piece of code: > > > > id = (dtrace_id_t)(uintptr_t)vmem_alloc(dtrace_arena, 1, > > VM_BESTFIT | VM_SLEEP); > > > > id is uint32_t, and I think id is used as an index to array > dtrace_probes[] > > but why not just use id = cur_value + 1, cur_value is a global variable > to > > record the lastest id? > > Is this a trick? for what? > > Using the vmem allocator to allocate integers is fairly common > practice in Solaris. It provides a number of things that > "cur_value++" doesn't provide; among them: > > - Inexpensive (no scanning) reuse of free low numbers, which is > important if you're allocating array indicies. "cur_value++" just > grows without bound and provides no reuse. > > - Free debug tools in mdb and statistics in kstat. > > - Support routines for walking the list of allocated integers > (iterators) and test/assertion functions for checking allocations. > > - Locking for MT -- your 'cur_value' example would be incorrect for > most kernel uses in Solaris if it didn't include a mutex. > > - Callbacks for allocation of new integers, which can be used to > resize indexed arrays when needed. > > - Sleeping and non-sleeping allocation schemes; useful for different > operating contexts. > > It's also simple. > > There are probably more advantages that I can't think of at the > moment. ;-} > > -- > James Carlson, Solaris Networking <[EMAIL PROTECTED]> > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 >
_______________________________________________ dtrace-discuss mailing list [email protected]
