[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
BOUNCE rtl@rtlinux.org: Approval required: Non-member submissionfrom ["chandu Reddy" <chandureddy@hclt.com>] (fwd)
- To: rtl@rtlinux.org
- Subject: BOUNCE rtl@rtlinux.org: Approval required: Non-member submissionfrom ["chandu Reddy" <chandureddy@hclt.com>] (fwd)
- From: Der Herr Hofrat <der.herr@hofr.at>
- Date: Fri, 18 May 2001 16:13:37 +0200 (CEST)
>From owner-rtl Fri May 18 01:36:57 2001
Received: from saraswathi.hclt.co.in ([202.54.64.6])
by hq.fsmlabs.com (8.11.2/8.11.2) with ESMTP id f4I7aur24939
for <rtl@fsmlabs.com>; Fri, 18 May 2001 01:36:56 -0600
Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
id K82SZHZB; Fri, 18 May 2001 13:14:16 +0530
Received: from CHANDUREDDY ([192.168.210.11]) by sakthi.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
id KW5J835G; Fri, 18 May 2001 13:03:38 +0530
Message-ID: <018d01c0df92$92d0a360$0bd2a8c0@hclt.com>
From: "chandu Reddy" <chandureddy@hclt.com>
To: <rtl@fsmlabs.com>
References: <20010515215032.CB08610AA0@denx.denx.de> <3B024373.99329173@robo.fe.uni-lj.si>
Subject: Re: [rtl] Shared memory synchronization
Date: Fri, 18 May 2001 13:03:34 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
HI
regarding Shared memory synchronisation,
u can refer the article in Dr. Dobb's Journal dated November 1999.
it is given with out using mbuff driver. u can use the same concept
here.
Chandu
These are my personal interests and openions.
----- Original Message -----
From: Ales Bardorfer <alesb@robo.fe.uni-lj.si>
To: <rtl@fsmlabs.com>
Sent: Wednesday, May 16, 2001 10:08 AM
Subject: [rtl] Shared memory synchronization
> I posted this before, but it seems there have been some problems with
> the mailing list. So, here it is again:
>
> I have some problems synchronizing shared mem access.
>
> My RT-thread uses shared memory (mbuff) to get some info what to do. I
> would like to be changing this shared memory from user space. Thus to
> ensure the atomic changes of the shm data, I created two identical
> structures in shm and a variable to point to the valid part of the data.
> >From user space I allways change the "other part", the one which is not
> being used by RT-thread. Like this:
>
> struct {
> int valid_part;
> struct actual_data[2];
> } my_data;
>
> shm = (my_data *)mbuff_alloc(...)
>
> Periodic RT-thread:
> pthread_wait_np();
> int valid_part = shm->valid_part;
> /* Read from and write to shm */
> a = shm->actual_data[valid_part].something;
> shm->actual_data[valid_part].something_else = b;
> ...
>
> User space:
> shm = (my_data *)mbuff_alloc(...)
> /* We are only allowed to change the non valid part! */
> int non_valid_part = !shm->valid_part;
>
> /* Change data in shm */
> shm->actual_data[non_valid_part].something = changed_value;
> ...
>
> /* At the end change the pointer! */
> shm->valid_part = non_valid_part;
>
>
> The main problem is the changing of this pointer (shm->valid_part). I
> guess this should not be the problem on a 1-CPU machine, but on a SMP I
> get lots of errors.
> What synchonizing mechanism should I use? Are mutexes or semaphores the
> right answer for that? I am relatively new to mutexes and semaphores,
> but is it safe to use mutexes, which might block the execution, in
> RT-thread? I would only like to (efficiently = no CPU load) block the
> user space thread, to wait for the RT-thread to finish, and then the
> user space thread can safely change the pointer.
>
> Is that possible and how? Is my approach with two identical structures
> and a "valid pointer" right, or should I use some other approach?
>
> Regards,
> Ales
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail majordomo@rtlinux.org OR
> echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.org
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
>