From: Jonathan Larmour <jifl@jifvik.org>
To: "Øyvind Harboe" <oyvind.harboe@zylin.com>
Cc: Jerome Souquieres <jerome.souquieres@kis.fr>,
ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Lightweight C++ multithreaded exceptions
Date: Tue, 24 May 2005 08:48:00 -0000 [thread overview]
Message-ID: <42921638.1090405@jifvik.org> (raw)
In-Reply-To: <1116843565.19282.8.camel@localhost.localdomain>
Ãyvind Harboe wrote:
> On Mon, 2005-05-23 at 11:52 +0200, Jerome Souquieres wrote:
>
>> That's interesting. However, from what I understand, this approach
>>only solves the multithreaded exceptions problem. This does nothing to
>>ensure that the standard C++ library (including STL) is thead safe. Am
>>I right ?
>
>
> I know there are some atomicity issues, but is that already handled in a
> CPU architecture specific but os-independent fashion by default in
> libstdc++?
libstdc++ has atomicity primitives for some CPUs, including x86, m68k,
mips, powerpc and SPARC. Notably it doesn't include ARM, probably because
at least on some ARM architecture versions it isn't possible. I don't know
for definite about recent ARM architecture versions.
But even that little atomicity support is only used in a handful of
places, and on unsupported architectures it falls back to mutexes if
available. However the key issue is that STL primarily uses OS mutexes if
available, and also needs "once" variables. Without those, it is not
thread-safe.
> Does anyone know of a definitive list of issues w.r.t. libstdc++ &
> multithreading?
There is support for multithreading, but you have to do it its way.
It's possible to hack it of course, but to do it the right way takes more
effort. Certainly I had to make other changes to eCos (and the tools) to
properly pass the libstdc++ testsuite. As you may have seen, there's a lot
of tests there!
It's probably inappropriate for me to comment on your suggested changes to
kernel rescheduling to support the fc_static munging, but personally I
don't believe kernel modifications are the right way. I know, I know,
sitting here with it all working, I would say that wouldn't I :-).
> I guess the fact that eCosCentric is destined to contribute their
> libstdc++ support saps my initiative for contributing patches in this
> area.
While that is ultimately true, as I indicated before, it will not be in
the near future. Anyone who hopes to hang on a bit in their project for it
to be released publically is likely to be disappointed.
> Even more so, because I have a solution for my needs.
Your patches and instructions will certainly work in some situations. Some
of it was using the code I included for our own C++ support anyway but did
release :-), e.g. CYGPKG_LIBC_I18N_NEWLIB_CTYPE. But there are definitely
a lot of gotchas once you introduce variation, including when you change
to different architectures or try to use the libstdc++ library itself.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next prev parent reply other threads:[~2005-05-23 17:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-23 9:13 Øyvind Harboe
2005-05-23 12:52 ` Jerome Souquieres
2005-05-23 13:25 ` Øyvind Harboe
2005-05-24 8:48 ` Jonathan Larmour [this message]
2005-05-24 9:01 ` Øyvind Harboe
2005-05-24 9:13 ` Paul D. DeRocco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42921638.1090405@jifvik.org \
--to=jifl@jifvik.org \
--cc=ecos-discuss@sources.redhat.com \
--cc=jerome.souquieres@kis.fr \
--cc=oyvind.harboe@zylin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).