Re: [SDO] Thread safety ?

[Yang ZHONG <le...@gmail.com>]

Maybe we can also consider Thread Safety from another perspective: User
Experience.
That makes the following discussion also apples to SDO Java.

SDO has two parts: metadata and instances.
Some modeling frameworks go as far as metadata are also instances of other
metadata,
it's out of scope of normal users.
Many SDO users do not expect "instances" thread-safe:
1. Thread-safe *instances* have overhead which single-thread users and
thread-"instance" users don't want
2. Users do not necessarily use the "instance" itself as the lock, e.g. they
may use a lock to synchronize collection of Data Graphs, processing,
resource accessing and so on

Many SDO users do expect "metadata" are thread-safe:
1. create "instances" from same Type on different threads
2. retrieve same Type/Property info on different threads
3. checking isInstanceOf against same Type on different threads

Hope we can keep improving SDO User Experience.

-- 

Yang ZHONG

Re: [SDO] Thread safety ?

[Geoffrey Winn <ge...@googlemail.com>]

I've just checked in a change to SDODate.cpp so that we define a macro
called tuscany_localtime_r and set it to whichever is appropriate for Linux
or MS VC8 and then use the macro wherever we would have called localtime.
The macro is guarded by an #ifndef so you can override it with a compiler
switch if needs be.

Regards,

Geoff.

On 20/12/06, Caroline Maynard <ca...@gmail.com> wrote:
>
> On 14/12/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> >
> > I've just checked in the change for localtime, replacing it with
> > localtime_r
> > on Unix and localtime_s on Windows.
>
>
> Ah. Unfortunately this is a backward compatibility issues with MS
> compilers.
> localtime_s() does not exist in VC++ 6. But localtime() is deprecated in
> VC++ 8 in favour of localtime_s(). See
>
> http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/f712f39b702000af
> ?
>
> Unless you intend to drop support for VC++ 6 users, you'll need to use a
> preprocessor macro, like _MSC_VER*, *to check which function  to use.
>
> In case you're wondering how the PHP engine does this, it defines a macro
> php_localtime_r, which is always used internally in place of any localtime
> variant. This uses localtime_r, if it is available. If the system doesn't
> have localtime_r, then it uses localtime but adds its own locking around
> the
> call. It never invokes localtime_s. Gory details in
> http://cvs.php.net/viewvc.cgi/php-src/main/reentrancy.c.
>
> You may deduce from this that the best solution for me would be if you
> were
> to introduce, say, tuscany_localtime_r, to do whatever you want to do for
> your general user, and which I could then redefine to php_localtime_r.
>
> --
> Caroline
>
>

Re: [SDO] Thread safety ?

[Caroline Maynard <ca...@gmail.com>]

On 14/12/06, Geoffrey Winn <ge...@googlemail.com> wrote:
>
> I've just checked in the change for localtime, replacing it with
> localtime_r
> on Unix and localtime_s on Windows.


Ah. Unfortunately this is a backward compatibility issues with MS compilers.
localtime_s() does not exist in VC++ 6. But localtime() is deprecated in
VC++ 8 in favour of localtime_s(). See
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/f712f39b702000af
?

Unless you intend to drop support for VC++ 6 users, you'll need to use a
preprocessor macro, like _MSC_VER*, *to check which function  to use.

In case you're wondering how the PHP engine does this, it defines a macro
php_localtime_r, which is always used internally in place of any localtime
variant. This uses localtime_r, if it is available. If the system doesn't
have localtime_r, then it uses localtime but adds its own locking around the
call. It never invokes localtime_s. Gory details in
http://cvs.php.net/viewvc.cgi/php-src/main/reentrancy.c.

You may deduce from this that the best solution for me would be if you were
to introduce, say, tuscany_localtime_r, to do whatever you want to do for
your general user, and which I could then redefine to php_localtime_r.

-- 
Caroline

Re: [SDO] Thread safety ?

[Geoffrey Winn <ge...@googlemail.com>]

I've just checked in the change for localtime, replacing it with localtime_r
on Unix and localtime_s on Windows.

Geoff.

On 09/12/06, Yang ZHONG <le...@gmail.com> wrote:
>
> Maybe we can also consider Thread Safety from another perspective: User
> Experience.
> That makes the following discussion also apples to SDO Java.
>
> SDO has two parts: metadata and instances.
> Some modeling frameworks go as far as metadata are also instances of other
> metadata,
> it's out of scope of normal users.
> Many SDO users do not expect "instances" thread-safe:
> 1. Thread-safe *instances* have overhead which single-thread users and
> thread-"instance" users don't want
> 2. Users do not necessarily use the "instance" itself as the lock, e.g.
> they
> may use a lock to synchronize collection of Data Graphs, processing,
> resource accessing and so on
>
> Many SDO users do expect "metadata" are thread-safe:
> 1. create "instances" from same Type on different threads
> 2. retrieve same Type/Property info on different threads
> 3. checking isInstanceOf against same Type on different threads
>
> Hope we can keep improving SDO User Experience.
>
> --
>
> Yang ZHONG
>
>