Re: [SDO C++] Thread safety ?

[Jean-Sebastien Delfino <js...@apache.org>]

Caroline Maynard wrote:
> On 21/11/06, Geoffrey Winn <ge...@googlemail.com> wrote:
>>
>>
>> As far as SDO itself is concerned, I think we would be OK if the user of
>> SDO
>> could guarantee that whenever an SDO artifact (data factory, data 
>> object,
>> type, XSDHelper ...) is created then that artifact will be used
>> _exclusively_ by the thread that created it. If that's acceptable to you
>> then I'll check the code to ensure that my claim is correct.
>
>
> Yes, that's how it would be. The SDO for PHP implementation doesn't keep
> references to Tuscany objects in static data.
>
> As you observed earlier we will need to resolve the localtime issue.
>
>
> I'll raise a JIRA for that.
>
> Outside of SDO we will also need to check the various libraries that we
>> depend on. You mentioned libxml2 but there is also zlib and iconv too.
>> Based
>> on a quick look at the libxml2 reference that you supplied we wll need a
>> small change to the SDO build process but also possibly some code 
>> changes
>> too.
>
>
> Both zlib and iconv are also part of the normal PHP environment, because
> libxml2 depends on them, so I don't expect issues with them. But FYI, 
> zlib
> has a faq: http://www.zlib.net/zlib_faq.html#faq21
> As for iconv, I think that libxml2 will use whatever iconv 
> implementation it
> finds on the platform, which is not necessarily libiconv, so a general
> statement may not be possible.
>

Do you think that we should build with the thread safe libs by default? 
or have 2 bin libraries one thread safe, one not but faster?

The question applies to both Linux and Windows, and I'm not sure but we 
may have different answers for different systems.

Caroline, maybe I missed it in the email thread, but do your users need 
this on Linux? Windows? both?

Thanks,

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

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
>
>

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 C++] Thread safety ?

[Jean-Sebastien Delfino <js...@apache.org>]

Caroline Maynard wrote:
>>
>> What do you mean by "maintain the status of the thread-safe variant"?
>> document it? continue to make sure that it works when adding new code?
>> anything else?
>
>
> I meant the latter - with quite a few different  people contributing code
> and patches,  there's  a likelihood that new thread-unsafe code may be
> introduced.
>

Caroline,

Since the default Apache Httpd win32 distribution is multi-threaded, 
scenarios running in this environment (like BigBank) will run into any 
multi-threading issues right away (I believe that this is what we're 
running into with the HttpdBigBank scenario now). I think that we can 
use these scenarios get to get a good indication of how well we work in 
a multi-threaded environment for now, then later put together some test 
cases that explicitly test multithreading.

Does anybody already have any multi-threaded test case for SDO? or would 
like to help with that?

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [SDO C++] Thread safety ?

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

On 01/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:

>
> OK, I was asking because it seems more interesting to support threaded
> MPMs on Windows (as a threaded MPM is the default) than on Linux/Unix
> where I think the majority of people use forking/multi-process MPMs.
>
> So I was initially thinking of having the default binary distribution be
> multi-threaded on Windows and mono-threaded on Linux, but I'm interested
> in your input and what you've seen in terms of "actual" usage on both
> platforms. We know that, as you said, pretty much all options are
> possible on all platforms, and people are expecting binary distributions
> on Windows but in general build from source on Linux, but I'm looking
> for the right defaults...


I would agree with those defaults for the binaries, provided there's no
negative effects for the non-threaded Windows user.

> Have you considered how to maintain the status of the thread-safe
> > variant as new code is added?
>
> What do you mean by "maintain the status of the thread-safe variant"?
> document it? continue to make sure that it works when adding new code?
> anything else?


I meant the latter - with quite a few different  people contributing code
and patches,  there's  a likelihood that new thread-unsafe code may be
introduced.

-- 
Caroline

Re: [SDO C++] Thread safety ?

[Jean-Sebastien Delfino <js...@apache.org>]

Caroline Maynard wrote:
> On 01/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>>
>> Do you think that we should build with the thread safe libs by default?
>> or have 2 bin libraries one thread safe, one not but faster?
>>
>
>
>> The question applies to both Linux and Windows, and I'm not sure but we
>> may have different answers for different systems.
>
>
> This isn't important for the PHP implementation, because we build the
> Tuscany code from source at present, so all we need is a compile 
> switch. But
> in general, the expectation is that binaries are provided for Windows, 
> but
> *IX users will build it themselves.
>
> Caroline, maybe I missed it in the email thread, but do your users need
>> this on Linux? Windows? both?
>
>
> Both. Actually anywhere where they might be running an Apache HTTP Server
> with a threaded MPM and MOD_PHP. For example FreeBSD, Linux AMD_64 or 
> Mac OS
> X, to name but a few.

OK, I was asking because it seems more interesting to support threaded 
MPMs on Windows (as a threaded MPM is the default) than on Linux/Unix 
where I think the majority of people use forking/multi-process MPMs.

So I was initially thinking of having the default binary distribution be 
multi-threaded on Windows and mono-threaded on Linux, but I'm interested 
in your input and what you've seen in terms of "actual" usage on both 
platforms. We know that, as you said, pretty much all options are 
possible on all platforms, and people are expecting binary distributions 
on Windows but in general build from source on Linux, but I'm looking 
for the right defaults...

>
> Have you considered how to maintain the status of the thread-safe 
> variant as
> new code is added?

What do you mean by "maintain the status of the thread-safe variant"? 
document it? continue to make sure that it works when adding new code? 
anything else?

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [SDO C++] Thread safety ?

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

On 01/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:

>
> Do you think that we should build with the thread safe libs by default?
> or have 2 bin libraries one thread safe, one not but faster?
>


> The question applies to both Linux and Windows, and I'm not sure but we
> may have different answers for different systems.


This isn't important for the PHP implementation, because we build the
Tuscany code from source at present, so all we need is a compile switch. But
in general, the expectation is that binaries are provided for Windows, but
*IX users will build it themselves.

Caroline, maybe I missed it in the email thread, but do your users need
> this on Linux? Windows? both?


Both. Actually anywhere where they might be running an Apache HTTP Server
with a threaded MPM and MOD_PHP. For example FreeBSD, Linux AMD_64 or Mac OS
X, to name but a few.

Have you considered how to maintain the status of the thread-safe variant as
new code is added?
-- 
Caroline