public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: sandeep <shimple0@yahoo.com>
To: sandeep <shimple0@yahoo.com>
Cc: ecos-devel@ecos.sourceware.org, ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] [SMP]serious bug in synchronisation primitives
Date: Wed, 27 Oct 2004 17:19:00 -0000	[thread overview]
Message-ID: <417FDBDB.4010106@yahoo.com> (raw)
In-Reply-To: <417F9890.7080209@yahoo.com>

A quick solution (for time being) that can take care of majority (haven't looked 
if it will take care of all the situations) of problem situations, would be to 
do CYG_KERNEL_CPU_THIS() involving array accesses in simple inline accessor 
functions in sched.hxx under disable---restore interrupts protection, to ensure 
that invoking thread does not get scheduled out in middle of it.

however it is a costly solution, considering that these inlines would be called 
quite often. if possible, better solutions would be preferrable.

in case we go with disable--restore model to handle the problem in global way, 
could it be possible to have slightly separate names macros for 
disabling--restoring the interrupts here?

considering the SMP HAL i have worked with so far, i would prefer using slightly 
tweaked versions/ asm-inlines if needed, that reduce the instructions involved 
in the process as compared to normal DISABLE-RESTORE, taking advantage of the 
fact that I need to do it for a very small section of code, for a small time and 
that no switching etc. will be happening during it.

if modifications were to be done in HAL, would have done by now. would avoid 
making modifications in non-HAL code as far as possible, to make it convenient 
to keep in sync with regular eCos cvs.

as one colleague mentioned, this could be possibly last stumbling block in 
getting a stable SMP eCos on SOC architecture we have worked upon.

comments/feedbacks awaited.

sandeep

           reply	other threads:[~2004-10-27 17:19 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <417F9890.7080209@yahoo.com>]

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=417FDBDB.4010106@yahoo.com \
    --to=shimple0@yahoo.com \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=ecos-discuss@sources.redhat.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).