Hi,

I am writing an opcode that buffers incoming data in frames which are used for further processing.  I would also like it so the amount of frames buffered can be changed at k-rate during runtime but I would also like to make it so there doesn't have to be a hard limit on the maximum amount of frames that can be buffered at initialisation. It seems then that I will need to re-allocated my buffer during performance. 

I am not very experienced in multi-threaded programming and was wondering what the best way to go about this is, would I have to write logic using pthreads and perhaps atomics to do the reallocation in a different thread? Then signal the main process when the allocation has successfully completed? 

As a small aside Apple's GCD seems to have a very nice API for doing processes in a background thread then notifying the main thread which makes this process a lot easier, an example would be something I found on Stackoverflow like:

// ... task 1 on main thread
dispatch_async(other_queue, ^{
    // ... task 2 in background thread
    dispatch_async(dispatch_get_main_queue(), ^{
        // ... task 3 on main thread
    });
});

http://stackoverflow.com/questions/13079963/how-to-send-a-message-or-notification-to-main-thread-in-x-code/13080519#13080519

Is there an equivalent to this in C++ perhaps which would do what I require in a similar fashion and would not block the main process thread?

Thanks

Ed

 

Whatever you do, don't allocate it in the processing thread. Start a thread using the Csound threading interface, allocate memory and then swap the pointers (with a 

lock protecting it), signal the change if needed,  then deallocate the old

pointer and finish the thread. You might not need to complicate it any further.

Victor Lazzarini

Dean of Arts, Celtic Studies, and Philosophy

Maynooth University

Ireland

On 13 Jan 2017, at 22:52, Ed Costello <phasereset@GMAIL.COM> wrote:

Hi,

I am writing an opcode that buffers incoming data in frames which are used for further processing.  I would also like it so the amount of frames buffered can be changed at k-rate during runtime but I would also like to make it so there doesn't have to be a hard limit on the maximum amount of frames that can be buffered at initialisation. It seems then that I will need to re-allocated my buffer during performance. 

I am not very experienced in multi-threaded programming and was wondering what the best way to go about this is, would I have to write logic using pthreads and perhaps atomics to do the reallocation in a different thread? Then signal the main process when the allocation has successfully completed? 

As a small aside Apple's GCD seems to have a very nice API for doing processes in a background thread then notifying the main thread which makes this process a lot easier, an example would be something I found on Stackoverflow like:

// ... task 1 on main thread
dispatch_async(other_queue, ^{
    // ... task 2 in background thread
    dispatch_async(dispatch_get_main_queue(), ^{
        // ... task 3 on main thread
    });
});

http://stackoverflow.com/questions/13079963/how-to-send-a-message-or-notification-to-main-thread-in-x-code/13080519#13080519

Is there an equivalent to this in C++ perhaps which would do what I require in a similar fashion and would not block the main process thread?

Thanks

Ed

 

If you use std::vector() you really need to re-implement new/delete to use the Csound memory allocation mechanism 
as Mike said, because otherwise things might not tie in very well with the Csound engine. Anything like resizing has
to happen in another thread. Resize will also need to use csound->ReAlloc (if you are using csound->Malloc). 
Not quite sure whether it’s worth the trouble.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 14 Jan 2017, at 17:25, Ed Costello  wrote:
> 
> Yeah I figured that using Csounds allocator would be best practice, I will look into using Csounds threading interface and C++ futures also. I have been using std::vector in my code, would it be even more convenient just to use the vector resize method in another thread?
> Ed
> 
> On 14 January 2017 at 12:51, Michael Gogins  wrote:
> Yes, look at futures in the standard c++11 library. 
> 
> Regards, 
> Mike
> 
> On Jan 13, 2017 5:51 PM, "Ed Costello"  wrote:
> Hi,
> 
> I am writing an opcode that buffers incoming data in frames which are used for further processing.  I would also like it so the amount of frames buffered can be changed at k-rate during runtime but I would also like to make it so there doesn't have to be a hard limit on the maximum amount of frames that can be buffered at initialisation. It seems then that I will need to re-allocated my buffer during performance. 
> I am not very experienced in multi-threaded programming and was wondering what the best way to go about this is, would I have to write logic using pthreads and perhaps atomics to do the reallocation in a different thread? Then signal the main process when the allocation has successfully completed? 
> As a small aside Apple's GCD seems to have a very nice API for doing processes in a background thread then notifying the main thread which makes this process a lot easier, an example would be something I found on Stackoverflow like:
> 
> // ... task 1 on main thread
> 
> dispatch_async
> (other_queue, ^{
> 
>     
> // ... task 2 in background thread
> 
>     dispatch_async
> (dispatch_get_main_queue(), ^{
> 
>         
> // ... task 3 on main thread
> 
>     
> });
> });
> http://stackoverflow.com/questions/13079963/how-to-send-a-message-or-notification-to-main-thread-in-x-code/13080519#13080519
> 
> Is there an equivalent to this in C++ perhaps which would do what I require in a similar fashion and would not block the m

The standard C++ library does not parametrize thread launching
facilities in the same way that it parametrizes memory allocators and
deallocators. So when using  or  we would be stuck with
implementation-defined thread launching and joining.

However, I do not view this as a real problem because  truly
is a standard. A minor problem might arise if
std::thread::native_handle_type was different in some build of Csound
compared with Csound's thread handle type. This would only matter in
practice if Csound's threading facilities tried to work with 
threads, or vice versa.

std::vector is not thread safe, you would have to protect the vector
against data races if resizing in one thread while using in another
thread.

Regards,
Mike



-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sat, Jan 14, 2017 at 12:25 PM, Ed Costello  wrote:
> Yeah I figured that using Csounds allocator would be best practice, I will
> look into using Csounds threading interface and C++ futures also. I have
> been using std::vector in my code, would it be even more convenient just to
> use the vector resize method in another thread?
> Ed
>
> On 14 January 2017 at 12:51, Michael Gogins 
> wrote:
>>
>> Yes, look at futures in the standard c++11 library.
>>
>> Regards,
>> Mike
>>
>> On Jan 13, 2017 5:51 PM, "Ed Costello"  wrote:
>>>
>>> Hi,
>>>
>>> I am writing an opcode that buffers incoming data in frames which are
>>> used for further processing.  I would also like it so the amount of frames
>>> buffered can be changed at k-rate during runtime but I would also like to
>>> make it so there doesn't have to be a hard limit on the maximum amount of
>>> frames that can be buffered at initialisation. It seems then that I will
>>> need to re-allocated my buffer during performance.
>>> I am not very experienced in multi-threaded programming and was wondering
>>> what the best way to go about this is, would I have to write logic using
>>> pthreads and perhaps atomics to do the reallocation in a different thread?
>>> Then signal the main process when the allocation has successfully completed?
>>> As a small aside Apple's GCD seems to have a very nice API for doing
>>> processes in a background thread then notifying the main thread which makes
>>> this process a lot easier, an example would be something I found on
>>> Stackoverflow like:
>>>
>>> // ... task 1 on main thread
>>> dispatch_async(other_queue, ^{
>>>     // ... task 2 in background thread
>>>     dispatch_async(dispatch_get_main_queue(), ^{
>>>         // ... task 3 on main thread
>>>     });
>>> });
>>>
>>>
>>> http://stackoverflow.com/questions/13079963/how-to-send-a-message-or-notification-to-main-thread-in-x-code/13080519#13080519
>>>
>>> Is there an equivalent to this in C++ perhaps which would do what I
>>> require in a similar fashion and would not block the main process thread?
>>> Thanks
>>> Ed
>>>
>

Vector allocation and deallocation can be done either by overriding
operators new and delete, or by providing a custom implementation of
std::allocator as a template argument to the std::vector declaration.

I don't think std::vector<>::resize() would have to use
csound->ReAlloc, but I'm not 100% sure.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sat, Jan 14, 2017 at 12:32 PM, Victor Lazzarini
 wrote:
> If you use std::vector() you really need to re-implement new/delete to use the Csound memory allocation mechanism
> as Mike said, because otherwise things might not tie in very well with the Csound engine. Anything like resizing has
> to happen in another thread. Resize will also need to use csound->ReAlloc (if you are using csound->Malloc).
> Not quite sure whether it’s worth the trouble.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 14 Jan 2017, at 17:25, Ed Costello  wrote:
>>
>> Yeah I figured that using Csounds allocator would be best practice, I will look into using Csounds threading interface and C++ futures also. I have been using std::vector in my code, would it be even more convenient just to use the vector resize method in another thread?
>> Ed
>>
>> On 14 January 2017 at 12:51, Michael Gogins  wrote:
>> Yes, look at futures in the standard c++11 library.
>>
>> Regards,
>> Mike
>>
>> On Jan 13, 2017 5:51 PM, "Ed Costello"  wrote:
>> Hi,
>>
>> I am writing an opcode that buffers incoming data in frames which are used for further processing.  I would also like it so the amount of frames buffered can be changed at k-rate during runtime but I would also like to make it so there doesn't have to be a hard limit on the maximum amount of frames that can be buffered at initialisation. It seems then that I will need to re-allocated my buffer during performance.
>> I am not very experienced in multi-threaded programming and was wondering what the best way to go about this is, would I have to write logic using pthreads and perhaps atomics to do the reallocation in a different thread? Then signal the main process when the allocation has successfully completed?
>> As a small aside Apple's GCD seems to have a very nice API for doing processes in a background thread then notifying the main thread which makes this process a lot easier, an example would be something I found on Stackoverflow like:
>>
>> // ... task 1 on main thread
>>
>> dispatch_async
>> (other_queue, ^{
>>
>>
>> // ... task 2 in background thread
>>
>>     dispatch_async
>> (dispatch_get_main_queue(), ^{
>>
>>
>> // ... task 3 on main thread
>>
>>
>> });
>> });
>> http://stackoverflow.com/questions/13079963/how-to-send-a-message-or-notification-to-main-thread-in-x-code/13080519#13080519
>>
>> Is there an equivalent to this in C++ perhaps which would do what I require in a similar fashion and would not block the main process thread?
>> Thanks
>> Ed
>>
>>

If the allocator uses csound->Malloc(), the only sane way to grow the memory is to use csound->ReAlloc() (unless you want to reimplement it using
csound->Malloc() and Free()) , so resize() would need to do that if the memory needs to be expanded.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 14 Jan 2017, at 17:54, Michael Gogins  wrote:
> 
> Vector allocation and deallocation can be done either by overriding
> operators new and delete, or by providing a custom implementation of
> std::allocator as a template argument to the std::vector declaration.
> 
> I don't think std::vector<>::resize() would have to use
> csound->ReAlloc, but I'm not 100% sure.
> 
> Regards,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Sat, Jan 14, 2017 at 12:32 PM, Victor Lazzarini
>  wrote:
>> If you use std::vector() you really need to re-implement new/delete to use the Csound memory allocation mechanism
>> as Mike said, because otherwise things might not tie in very well with the Csound engine. Anything like resizing has
>> to happen in another thread. Resize will also need to use csound->ReAlloc (if you are using csound->Malloc).
>> Not quite sure whether it’s worth the trouble.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 14 Jan 2017, at 17:25, Ed Costello  wrote:
>>> 
>>> Yeah I figured that using Csounds allocator would be best practice, I will look into using Csounds threading interface and C++ futures also. I have been using std::vector in my code, would it be even more convenient just to use the vector resize method in another thread?
>>> Ed
>>> 
>>> On 14 January 2017 at 12:51, Michael Gogins  wrote:
>>> Yes, look at futures in the standard c++11 library.
>>> 
>>> Regards,
>>> Mike
>>> 
>>> On Jan 13, 2017 5:51 PM, "Ed Costello"  wrote:
>>> Hi,
>>> 
>>> I am writing an opcode that buffers incoming data in frames which are used for further processing.  I would also like it so the amount of frames buffered can be changed at k-rate during runtime but I would also like to make it so there doesn't have to be a hard limit on the maximum amount of frames that can be buffered at initialisation. It seems then that I will need to re-allocated my buffer during performance.
>>> I am not very experienced in multi-threaded programming and was wondering what the best way to go about this is, would I have to write logic using pthreads and perhaps atomics to do the reallocation in a different thread? Then signal the main process when the allocation has successfully completed?
>>> As a small aside Apple's GCD seems to have a very nice API for doing processes in a background thread then notifying the main thread which makes this process a lot easier, an example would be something I found on Stackoverflow like:
>>> 
>>> // ... task 1 on main thread
>>> 
>>> dispatch_async
>>> (other_queue, ^{
>>> 
>>> 
>>> // ... task 2 in background thread
>>> 
>>>    dispatch_async
>>> (dispatch_get_main_queue(), ^{
>>> 
>>> 
>>> // ... task 3 on main thread
>>> 
>>> 
>>> });
>>> });
>>> http://stackoverflow.com/questions/13079963/how-to-send-a-message-or-notification-to-main-thread-in-x-code/13080519#13080519
>>> 
>>> Is there an equivalent to this in C++ perhaps which would do what I require in a similar fashion and would not block the main process t