🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.nativeapi
Article #7560

Re: Accessing same variable from multiple threads

#7560
From: Remy Lebeau (TeamB)
Date: Wed, 19 Jan 2005 21:31
53 lines
3378 bytes
"Vladimir Afanasyev" <avv@systema.kiev.ua> wrote in message
news:41eea799$1@newsgroups.borland.com...

> It is not exactly because it's not clear from task when and
> how threads will work with variable.
>
> For example both threads access to variable asynchronous. Look.
>
> One thread modyfyes variable in 10:00 and 10:05.
>
> Another thread may read in 9:58, 10:02, 10:07.

You can't rely on that to provide safe access.  For instance, say the
reading thread begins reading the variable, then the OS task-switches to the
writing thread before the reading thread can finish reading the variable.
The writing thread alters the variable, then the OS task-switches back to
the reading thread, which then finishes reading the variable.  The reading
thread now has a corrupt value because it read bytes from two different time
periods.

That is why you should always synchronize access to shared data - because
you do not have control over when a thread will try to access that shared
variable.  A thread that wants to alter the variable should be made to wait
until after any reading threads have completely read all of the unaltered
bytes in full.

> If this threads doesn't know exactly when data was changed
> it may read it in any time or it must carefully track for changes.
> Critical sections doesn't help for tracking changes (or it must
> be called continuously).

You are missing the point.  In order for a thread to know that the data was
changed, thus needing to re-read teh new value, the thread still has to
access the variable in general.  That general access must be protected,
regardless of the reason for the access.

> I only say that it is not important to enter in critical section if
> unknown when changes were.

Of course it is important.

> Reading thread can enter before first writing or after but really reading
> thread must all time "listen" variable via critical section or semaphor.

Using a critical section or semaphor is completely meaningless unless all
involved thread use it.  You can't have just the reading thread only enter
the critical section and not have the writing thread as well.  The data is
will not be protected at all unless the writing thread enters the critical
section as well.


Gambit
Technical Details
Message-ID: <41eed116$1@newsgroups.borland.com>
Path: arc1-ca.pugleaf.net!g2news1.google.com!news3.google.com!news.glorb.com!solnet.ch!solnet.ch!newsfeed.freenet.de!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail
References: <41edea6b@newsgroups.borland.com> <41ee3727$1@newsgroups.borland.com> <41ee742e$1@newsgroups.borland.com> <41ee8f57$1@newsgroups.borland.com> <41ee9bd1$1@newsgroups.borland.com> <41eea799$1@newsgroups.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 10cc67,4809cdd9a7828fa7
X-Google-Attributes: gid10cc67,public
X-Google-Language: ENGLISH,ASCII-7-bit
From: "Remy Lebeau \(TeamB\)" <no.spam@no.spam.com>
Newsgroups: borland.public.cppbuilder.nativeapi
References:  <41edea6b@newsgroups.borland.com> <41ee3727$1@newsgroups.borland.com> <41ee742e$1@newsgroups.borland.com> <41ee8f57$1@newsgroups.borland.com> <41ee9bd1$1@newsgroups.borland.com> <41eea799$1@newsgroups.borland.com>
Subject: Re: Accessing same variable from multiple threads
Date: Wed, 19 Jan 2005 13:31:09 -0800
Lines: 55
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
NNTP-Posting-Host: 68.69.17.41
Message-ID: <41eed116$1@newsgroups.borland.com>
X-Trace: newsgroups.borland.com 1106170134 68.69.17.41 (19 Jan 2005 13:28:54 -0800)
Path: arc1-ca.pugleaf.net!g2news1.google.com!news3.google.com!news.glorb.com!solnet.ch!solnet.ch!newsfeed.freenet.de!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail