memset

조회수 4회
읽지 않은 첫 메시지로 건너뛰기

Jack Klein

읽지 않음,
1997. 11. 11. 오전 3:00:0097. 11. 11.
받는사람

Peter Mayne <Peter...@digital.com> wrote in article
<3467c3f7...@mrnews.mro.dec.com>...
> memset writes a value to "n" locations in memory, starting at
a given
> location.
>
> Some implementations may not have byte load/store operations.
Instead,
> an implementation may only be able to do longword aligned
longword
> load/store (where longword is 4 bytes).
>
> In this case, a memset of 2 bytes means that 4 bytes must be
read, 2
> bytes altered, and 4 bytes written. Normally, this wouldn't
matter,
> but in a multi-threaded environment, this is potentially
disastrous.
>
> How much memory is memset is actually allowed to read/write
(as
> opposed to set)? Is memset allowed some implementation defined
leeway
> as to how much memory is actually read/written?
>
> PJDM
> Digital Equipment Corporation (Australia), Canberra, ACT
>
-----------------------------------------------------------------
--------------
> These are my opinions, and have nothing to do with Digital.
> This was edited by a wheelbarrow full of walruses.

The standard actually does not address this issue at all. I
agree that this could cause a problem for certain types of
variable allocation in a multi-threaded environment, but the
standard does not support any type of multi-threading or
multi-tasking in any case.

I would think that there are several possible mitigations for
this situation.

The first is that many processors support an atomic memory
read/modify/write cycle which locks the memory bus so task
switches or indeterminate states cannot occur.

Another would be proper care in variable allocation in such a
way as to eliminate a problem.

Yet another would be to use some system specific resource
(mutex, semaphore, etc.) to guarantee exclusive access to the
region for the duration of the operation.

One more which occurs to me would be simply not to use memset()
in situations like this.

Jack


Peter Seebach

읽지 않음,
1997. 11. 11. 오전 3:00:0097. 11. 11.
받는사람

In article <648lsb$l...@bgtnsc02.worldnet.att.net>,
Jack Klein <jack...@worldnet.att.net> wrote:
[various ideas about what memset could do...]

Another comes to mind: The compiler can, at compile time, see how much
it knows about the arguments to memset (i.e., if an argument is &l, and
l is a long, it is presumably long-aligned...), and then it can generate
calls to an appropriate version.

I would be unsurprised to find a compiler smart enough to optimize
memcpy(&long1, &long2, sizeof(long));
into an assignment.

In short, it has to work, and whether it works slowly or quickly is
quality of implementation.

-s
--
se...@plethora.net -- Speaking for myself. No spam please.
Copyright 1997. All rights reserved. This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Stephan Wilms

읽지 않음,
1997. 11. 11. 오전 3:00:0097. 11. 11.
받는사람

Peter Mayne wrote:
>
> memset writes a value to "n" locations in memory, starting at a given
> location.
>
> Some implementations may not have byte load/store operations. Instead,
> an implementation may only be able to do longword aligned longword
> load/store (where longword is 4 bytes).
>
> In this case, a memset of 2 bytes means that 4 bytes must be read, 2
> bytes altered, and 4 bytes written. Normally, this wouldn't matter,
> but in a multi-threaded environment, this is potentially disastrous.
>
> How much memory is memset is actually allowed to read/write (as
> opposed to set)? Is memset allowed some implementation defined leeway
> as to how much memory is actually read/written?

Hi Peter Mayne,

The compiler must guaranty that "memset()" works exactly as documented.
It must start setting at the exact byte adress specified and set
exactly the specified number of bytes to 0. How this is done internally
is the compilers problem. He might treat non-aligned adresses by doing
bitwise operations to affect only the excact byte(s) specified. This
is not know and no specific algorithm is required. But you should be
aware that the algorithm might be much more complex then a simple loop.

And *IF* (ie. a big if) the processor is not capable of adressing
memory locations below a certain number of bits, it might decide to
define the C compiler byte size to be for instacne 16 or 32 bits.
The C standard allows this and the constant CHAR_BIT tells you how
many bits there are per byte.

Stephan
(initiator of the campaign against grumpiness in c.l.c)

Lawrence Kirby

읽지 않음,
1997. 11. 11. 오전 3:00:0097. 11. 11.
받는사람

In article <3467c3f7...@mrnews.mro.dec.com>
Peter...@digital.com "Peter Mayne" writes:

>memset writes a value to "n" locations in memory, starting at a given
>location.
>
>Some implementations may not have byte load/store operations. Instead,
>an implementation may only be able to do longword aligned longword
>load/store (where longword is 4 bytes).

In that case it is going to have problems dealing with any form of byte
access such as char variables and arrays of char, notably string data.
One solution to that is to make the size of char in the C implementation
equal to the size of the machine word.

>In this case, a memset of 2 bytes means that 4 bytes must be read, 2
>bytes altered, and 4 bytes written. Normally, this wouldn't matter,
>but in a multi-threaded environment, this is potentially disastrous.

The C language itself doesn't support multi-threaded environments. If the
particular compiler wants to it will have to do whatever is necessary.
Note that even so it will probably only do it for volatile variables since
these are the only ones that the stadnard gives any license at all for
for asynchronous access (and even then only strictly volatile sig_atomic_t)

>How much memory is memset is actually allowed to read/write (as
>opposed to set)?

As much as it likes as long as it doesn't break the behaviour of any
strictly conforming program (and strictly conforming programs aren't
multi-threaded).

>Is memset allowed some implementation defined leeway
>as to how much memory is actually read/written?

Again, as far as the C language is concerned, it can have as much leeway
as it wants as long as it doesn't break any strictly conforming program.
Note that the first argument to memset is void *, not volatile void *
so even if your implementation does the right thing for volatile objects
this need not apply to memset since it isn't required to treat the object
to be written as volatile.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Dan Pop

읽지 않음,
1997. 11. 11. 오전 3:00:0097. 11. 11.
받는사람

>In this case, a memset of 2 bytes means that 4 bytes must be read, 2
>bytes altered, and 4 bytes written. Normally, this wouldn't matter,
>but in a multi-threaded environment, this is potentially disastrous.

Standard C contains no support whatsoever for multi-threaded environments.
A C compiler can generate code which is not MT safe for *any* C construct
and no standard library function is guaranteed to be MT safe.

OTOH, there is nothing preventing an implementation from being MT safe.
The implementor must do "the right thing" for that.

>How much memory is memset is actually allowed to read/write (as

>opposed to set)? Is memset allowed some implementation defined leeway


>as to how much memory is actually read/written?

As far as the standard is concerned, memset is free to shuffle around the
contents of ALL the program's address space, but when it returns to its
caller, only the "n" bytes must be affected. The standard does not impose
any restriction on how memset (or any other standard library function)
performs its job, it only specifies what are the effects of memset, as
visible to a strictly conforming program.

No strictly conforming program can be multithreaded, because there is no
way to create a new thread without invoking undefined behaviour or using
language extensions which require diagnostics when compiled by a
standard-conforming implementation.

From a practical point of view, MT environments usually document which
library functions are MT-safe and which aren't. So, if memset is
documented as being MT-safe, the thread should only ensure that it has
exclusive access to the "n" characters before calling memset. If no such
guarantee exists, the program must provide its own replacement for memset
(using a different name, of course) that is implemented using only features
that are documented as being MT-safe.

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Peter Mayne

읽지 않음,
1997. 11. 11. 오전 3:00:0097. 11. 11.
받는사람

memset writes a value to "n" locations in memory, starting at a given
location.

Some implementations may not have byte load/store operations. Instead,
an implementation may only be able to do longword aligned longword
load/store (where longword is 4 bytes).

In this case, a memset of 2 bytes means that 4 bytes must be read, 2


bytes altered, and 4 bytes written. Normally, this wouldn't matter,
but in a multi-threaded environment, this is potentially disastrous.

How much memory is memset is actually allowed to read/write (as


opposed to set)? Is memset allowed some implementation defined leeway
as to how much memory is actually read/written?

PJDM

전체답장
작성자에게 답장
전달
새 메시지 0개