Do I need to lock a table during a FLUSH when using VSDK C++ API in multi-threaded app?

[Matthew Jew]

On Aug 16, 2006, at 1:44 AM, Ivan Smahin wrote:

> Hello Matthew,
>
> Wednesday, August 16, 2006, 11:23:55 AM, you wrote:
>
>> On Aug 16, 2006, at 12:03 AM, Ivan Smahin wrote:
>
>>> Hello Matthew,
>>>
>>> Wednesday, August 16, 2006, 12:42:43 AM, you wrote:
>>>
>>>> Hello,
>>>
>>>> I am using the VSDK 2 C++ in a multi-threaded application on a
>>>> Macintosh.
>>>
>>>> I normally use the API way to work with the database tables, so I
>>>> make sure
>>>> that I use semaphores/locks on each individual table whenever I
>>>> either read, modify, or add records.
>>>
>>>> My question is this:
>>>> If I do a flush() on a database, do I need to lock the tables
>>>> contained in that database
>>>> to prevent other threads from potentially attempting to read,  
>>>> modify,
>>>> or add records at the same time?
>>>> Or is the flush() operation implemented so that it does not  
>>>> interfere
>>>> with other threads
>>>> potentially accessing the tables contained in the database being
>>>> flushed?
>>>
>>>> What are the rules about locking tables for exclusive access now  
>>>> that
>>>> Valentina 2 now
>>>> is more thread-friendly?
>>>
>>>
>>> Currently  you  need lock/unlock every "kernel" object to make  
>>> sure be
>>> threading  safe.  So,  for  now,  global  mutex  seems to be most  
>>> safe
>>> solution.
>>>
>
>> Ivan,
>
>> When you say I need to lock/unlock every "kernel" object, what does
>> that mean exactly?
>
> Assume   you   get   some  table  pointer (pT1) and some field pointer
> ( pF1 = pT1->get_Field(1) ).
>
> The first thread call pT1->Drop_Field(1);
> The second thread call pf1->get_Value();
>
> It's just pseudo-code, but I think you will get the idea...
> So  it  is  not  enough to lock pT1 for threading-safe call of table's
> methods.  Because  another thread may use unlocked pF1 pointer. And so
> on...
>
> A lot of really possible scenarios could be imaging...
>
> So I would say - for now Valentina is threading unsafe. If you want to
> use it in multithreaded environment you need to use some global-guard
> policy.
>
> Again, I'm about 100% threading-safe solution.
>

Okay, I understand that.

I do use a lock for each table.

However, I am assuming that I can have one thread work with table 1,
and another thread working with table 2. This is okay in VSDK 2, yes?

- Matthew