In theory, there are 2 options:

(1) take a pointer to the shared data, and use a mutex to synchronize access to it.

(2) while Csound is in between processing buffers, you can copy to or from the shared data without a mutex.

In practice, I'm not aware that Csound itself has any mutexes or can get a mutex on any such shared data, so the only realistic alternative would appear to be 2. 

Furthermore, since Csound is itself single-threaded, if Csound did have a mutex, it would have to stop while another thread locked the mutex to read or write the shared data. The overhead and logic would then be the same as (2).

Bottom line: let the user play with copies of the data that you make in between processing buffers.

Regards,
Mike


-----Original Message-----
From: Iain Duncan 
Sent: Aug 22, 2005 4:12 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Problems with csoundTableGet()

>> But this produces a segfault, which does not happen if I comment out 
>> the csoundTableGet() call. ( No other routines try to use table_value 
>> in this example.)  So I guess I'm at a loss as to how to use the table 
>> get function at all without locking. Am I missing something? Attached 
>> is the whole file.

> Do not forget that the table may possibly not exist when you try to access
> it. Use csoundTableLength() to find out if the table number is valid and
> what is the maximum allowed table index.

Aack, I'm an idiot, that was it. I got mixed up and forgot you'd already 
mentioned that. So now it works with the call in the same loop as
csoundPerformKsmps().

If I want to use the resulting values taken out of the tables in another 
thread, and the other thread is just going to read the values, do I 
still have to protect the variables with mutex's? Perhaps put all the 
output variables in a structure that is protected? I guess if I know 
ahead of time what I will be getting in and out I can have one data 
object for all output, and then on every kpass, lock it, fill it up, 
unlock. And then do the same in the other threads.

Thanks so much for answering all my pestering guys. =)

Iain


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net