[Tdg] basic working scheduler

[Alex Norman]

I am suggestion that we consider it, yes.

-Alex

On  0, Wesley Smith <wesley.hoke at gmail.com> wrote:
> Are you suggesting using them for memory management with events?
> 
> wes
> 
> On 7/16/07, Alex Norman <alex at neisis.net> wrote:
> >On  0, Rama Hoetzlein <rch at umail.ucsb.edu> wrote:
> >>
> >> >
> >> >just because we use intrusive_ptrs doesn't mean you can't still create a
> >> >Blah *.
> >> >though for events I figure it is a good idea to use intrusive_ptrs 
> >instead
> >> >of *
> >> >for our functions, they make our interface easier to work with (and also
> >> >make
> >> >the "easy" interface easier).. I don't know what is so restrictive about
> >> >this.... though, I figure we should talk to the rest of the people about
> >> >this.
> >> >just check out intrusive_ptr, my vote is for using them instead of * as
> >> >much as
> >> >we can and therefore having everything be a subclass of "Object".  I 
> >like
> >> >the
> >> >idea of never calling delete and also not having memory leaks.
> >> >
> >> >
> >> It sounds like you're suggesting all future system and user events
> >> requiring intrusive_ptrs.
> >
> >I'm suggesting that we talk about it, I think it'll be a good idea.
> >
> >These intrusive_ptrs do not affect memory allocation, you still use new, 
> >and
> >delete is still called when objects fall out of scope for the last time, 
> >they
> >really just affect memory deallocation.
> >
> >> This means all users would have to adopt
> >> intrusive_ptrs if they want to work with the events they created. Even
> >> in their own seperate programs? Can you still just use a regular C
> >> pointer on them regardless? Does this add data to an event object?
> >
> >there is a reference count in the object class, so, there is an extra int 
> >per
> >object.
> >I don't know what you mean "use a regular C pointer on them", they replace 
> >C
> >pointers, yes, you can create an Object *, but our functions can either 
> >except
> >Object * or ObjectPtrs or both, we have to decide that.
> >I've used other libraries that provide reference counting and so they don't
> >accept normal "c pointers".
> >Basically, using these intrusive_ptrs (which are just a type of "smart 
> >pointer"
> >btw) makes our programming job (memory management) easier, though we have 
> >to
> >think about synchronization [though maybe we can use volatile 
> >sig_atomic_t?]
> >
> >> I
> >> thought we had already settled on an Event class design? How do 
> >intrusive_ptrs
> >> work? It seems in certain circumstances there might be a performance loss
> >> (e.g. you have a block of 100 events in a memory pool, just delete the 
> >whole
> >> block once). Overall, I'd like to hear more about the design impacts and
> >> discussion of intrusive_ptrs before we might adopt them.. Seems this 
> >might
> >> play a part in the memory pool design too.
> >
> >Basically, instead of allocating data and assigning it to a Blah * you 
> >assign it
> >to a boost::intrusive_ptr<Blah> x, and instead of passing around Blah * 
> >you pass
> >around boost::intrusive_ptr<Blah>.
> >every time a variable of type boost::intrusive_ptr<Blah> points to some 
> >data it
> >increments the reference associated with that data.  Every time that 
> >variable
> >falls out of scope (ie the block ends), the reference count is 
> >decremented..
> >once it reaches zero the memory is deallocated [or in our case would 
> >probably be
> >put back into the associated memory pool].
> >
> >Anyways, I figure these are worth a discussion, I like them, I'm going to 
> >be
> >using them or some other smart pointer instead of c pointers as much as I 
> >can in
> >my own projects in the future.. but if other people in the mint group 
> >aren't
> >into them then that is fine.. I can change the scheduler easily, but I 
> >think you
> >all should really check them out.
> >
> >> I like this design.. That would give you a periodic accuracy of 1 ms,
> >> and a triggered accuracy of ~nanoseconds. You basically sleep in 1 ms
> >> chunks. The only consequence is, to still relinquish CPU you could never
> >> do a <1 ms periodic event without having some dropped events somewhere.
> >> Assuming a thread control accuracy of 1 ms, I don't think there is any
> >> way around this though... The simple version, ~1 ms, sound like a good
> >> start.
> >
> >yeah, I figure the simple version is good for now and will get us going, 
> >if we
> >find that we need something more hardcore we'll change things up then.
> >
> >-Alex
> >
> >_______________________________________________
> >Tdg mailing list
> >Tdg at mat.ucsb.edu
> >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
> >
> _______________________________________________
> Tdg mailing list
> Tdg at mat.ucsb.edu
> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg