t_buffer / t_buffer_obj

    do.while
    Jan 04 2014 | 11:55 am
    Hi ! SDK 6.1.4 suggest to use "t_buffer_obj" instead of "t_buffer" .
    i would like to understand one difference that consist of accessing buffer data . If i want to access buffer data in old way , im simply pointing to 
    b->b_samples
b->b_framess
b->b_nchans
etc
    ... now this seems to be different ,and it consist of function call as i understand . so this is a new way of accessing that data right ? 
    buffer_getchannelcount(b);
buffer_getframecount(b);
    ... so now if i want to access and do operation/modify buffer sample content im not accessing it anymore through "b_samples" member . instead i should return a pointer to its content with :
    buffer_locksamples(b);
    ???
    so this is a new way of accessing buffer sample data , through locking buffer object ? which simply do two operations . Before it would require ATOMIC_INCREMENT , and calling for a member separately . Now its a one function . Do i understand it right ?
    I know the reason why i should lock the buffer , but it is always required ? cant i access samples without locking my buffers and compute some data out of it ? simply without modifying any buffer content .
    • do.while
      Jan 05 2014 | 10:58 am
      yes , thanks Nicolas , very informative
    • R∑N∑G∆D∑ R∆J∆
      Sep 03 2014 | 11:32 pm
      hmmm... this thread was only from january of this year, but there seems to be something missing...
      but since i'm in the process of figuring this out, in case it helps others searching in the future, i will take a guess: i take it the answer was that previously, we used to atomic_increment/decrement the 'b_inuse' flag of the old 't_buffer' struct (and also check the 'b_valid' flag). used to do these to ensure thread-safety.
      't_buffer' is deprecated and the new 't_buffer_obj' struct no longer has 'b_inuse'/'b_valid', so thread safety is ensured under-the-hood(so to speak) through these slightly less direct method calls? (previously, if someone had failed to set/check these flags properly and then tried to read/write from a buffer~ at the same time as another process was, it could cause probs? particularly if one of the processes was causing the data to change... but i never quite find an explanation of it at the thread-level...)
      edit: oops, this explains it: https://cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_appendix_d.html