Is .data reentrant? Is .bss?

[JoeCoder]

For Linux/UNIX, is it correct .bss is allocated from "heap" at execution time and therefore should be reentrant? What about .data? I would guess it's not since presumably it's part of the executable?

Where is this stuff documented? I'm sorry to be asking non-NASM related questions but I don't know where to find this stuff out since I am new to coding in this environment. Thanks guys.

[Frank Kotler]

I don't know about "reentrant" - depends on what you're doing with it, I think. .bss is nominally "uninitialized", but is in fact initialized to zero on startup (this is not the case with .bss in a .com file - otherwise it is, AFAIK). Both .data and .bss are "virtual memory" - unique to your "process", even though another process might share the same addresses.

For "reentrant", I think sys_fork gives you "different" (virtual) memory, but sys_clone shares memory - not sure about that one...

Best,
Frank

[Keith Kanios]

What precisely do you mean by reentrant? That particular concept is usually determined by how the code/processor accesses volatile data and not the data itself.

For Linux/UNIX, is it correct .bss is allocated from "heap" at execution time and therefore should be reentrant?

Perhaps from the viewpoint that the BSS section is immediately below the Heap.

I am not aware if the BSS section is technically allocated via a brk()/sbrk() equivalent during load... but I think with respect to your reentrancy question, it doesn't matter as the end result is a section of RAM marked as Read/Write and is thus volatile and global within, at least, the current process address space.

What about .data? I would guess it's not since presumably it's part of the executable?

Once the section is loaded into RAM, and is marked as Read/Write, it is the same situation as the BSS section.

Where is this stuff documented? I'm sorry to be asking non-NASM related questions but I don't know where to find this stuff out since I am new to coding in this environment. Thanks guys.

Not sure about official sources outside of reviewing the source code, but...

• ELF Startup State
• Process Address Space

[JoeCoder]

I don't know about "reentrant" - depends on what you're doing with it, I think. .bss is nominally "uninitialized", but is in fact initialized to zero on startup (this is not the case with .bss in a .com file - otherwise it is, AFAIK). Both .data and .bss are "virtual memory" - unique to your "process", even though another process might share the same addresses.

For "reentrant", I think sys_fork gives you "different" (virtual) memory, but sys_clone shares memory - not sure about that one...

Best,
Frank

Hi Frank. Thanks. What I am asking about I guess you could called thread-safety. I am used to calling it reentrancy what I mean is, when multiple copies of the executable are being executed, does each process or thread or whatever the unit of execution is, does it get its own copy of .bss and .data storage? It doesn't have to do with initialization. But you said both .data and .bss are unique to the process, I think that is what I wanted to know. And thanks for the note on fork/clone. That is also good to know.

Joe

[Keith Kanios]

What I am asking about I guess you could called thread-safety. I am used to calling it reentrancy

Clarification: Reentrancy vs Thread Safety @ Wikipedia.

what I mean is, when multiple copies of the executable are being executed, does each process or thread or whatever the unit of execution is, does it get its own copy of .bss and .data storage?

Conventionally: Process (separate virtual address space) yes, even via fork(). Thread (another unit of scheduling/execution within the current virtual address space), no... that is where things like Thread-Local Storage comes in.

[JoeCoder]

What precisely do you mean by reentrant? That particular concept is usually determined by how the code/processor accesses volatile data and not the data itself.

I guess it depends on the platform. What I was asking and I think Frank answered it, is the storage for .bss and .data unique to whatever the execution unit is? On the platform I work with, no program has the source level capability to be reentrant, if you use assembler you have to use system services to acquire any storage your workunit needs to be reentrant (threadsafe, process safe etc). There are various mechanisms that allow the application programmer to be more or less aware of it but in all cases it requires system calls by the compiler and is not a feature of the code itself. Whereas in Linux/UNIX it appears from your descriptions that just by using the correct sections you automatically get some level of reentrancy although maybe not thread safety in an assembly program. That isn't surprising because in MVS v. Linux/UNIX the address space and tasking  (process and threading) models are completely different.

For Linux/UNIX, is it correct .bss is allocated from "heap" at execution time and therefore should be reentrant?

Perhaps from the viewpoint that the BSS section is immediately below the Heap.

Thanks, that helps.

I am not aware if the BSS section is technically allocated via a brk()/sbrk() equivalent during load... but I think with respect to your reentrancy question, it doesn't matter as the end result is a section of RAM marked as Read/Write and is thus volatile and global within, at least, the current process address space.

As long as it's unique to the process then that should be what I was looking for. To summarize, would it be correct to say anything I code in .bss or .data is thread safe?

What about .data? I would guess it's not since presumably it's part of the executable?

Once the section is loaded into RAM, and is marked as Read/Write, it is the same situation as the BSS section.

Read/write isn't the issue so much as having only one workunit able to access it. You can have reentrant storage (at least in the environment I work in) that is writeable, the issue is it needs to be somehow workunit related and not global.

Thanks for the doc pointers.

Joe

[JoeCoder]

What I am asking about I guess you could called thread-safety. I am used to calling it reentrancy

Clarification: Reentrancy vs Thread Safety @ Wikipedia.

what I mean is, when multiple copies of the executable are being executed, does each process or thread or whatever the unit of execution is, does it get its own copy of .bss and .data storage?

Conventionally: Process (separate virtual address space) yes, even via fork(). Thread (another unit of scheduling/execution within the current virtual address space), no... that is where things like Thread-Local Storage comes in.

Thanks for the links, all this is pretty different from what I am used to. I'll read up on it. In MVS we have powerful control over storage management and can allocate storage to be shared by tasks (threads) or not, by other address spaces or not, etc.

[Keith Kanios]

To summarize, would it be correct to say anything I code in .bss or .data is thread safe?

Conventionally, no... quite the opposite actually (see my above reply).

[Rob Neff]

Perhaps a cheesy graphic will help:

Code: [Select]


         ProcessA                     ProcessB
   |------------------|          |------------------|
   |     Stack        |          |     Stack        |
   |----------------- |          |----------------- |
   |     Heap         |          |     Heap         |
   |----------------- |          |----------------- |
   |     .bss         |          |     .bss         |
   |------------------|          |------------------|
   |     .data        |          |     .data        |
   | -----------------|          | -----------------|
   |     .text        |          |     .text        |
   |     ThreadA      |          |     ThreadA      |
   |     ThreadB      |          |     ThreadB      |
   | -----------------|          | -----------------|


Reentrancy concerns are normally issues with function calls whereby the function must maintain separate instances of data on the stack for each invocation.
Threading issues usually involve synchronization of data (reader vs. writer) usually handled via some form of mutex.
In the picture above each process is separate and not aware of the other.  Each process has its own space in memory for code and data.
The threads within each process however have access to the same data within that process and thus any shared data must be synchronized to prevent things such as race conditions.
There are quite a few articles available on the 'net that discuss techniques for handling these issues.
Hopefully this unmuddies the waters a bit for you.

[JoeCoder]

Frank, Keith, Rob, thank you guys very much for your explanations, links, diagrams, and clarifications! You and this forum are a great resource.

The only way I know to ask some of these questions is to try to compare how I know things work on the system I use to what I am trying to learn here. I realize that is not ideal because things are so different (but I have no other frame of reference) for instance we have no stack, no heap, and you have work to do to make a program reentrant, especially in assembler. But once it is reentrant, you have to work pretty hard to cause a race condition (not our terminology btw). I realize I don't use the x86/UNIX terminology precisely yet, I apoligize for not stating my questions as clearly as they should be. I am not trying to learn how to do everything on day one so much as I am trying to learn how not to shoot myself in the foot on day one by making idiotic mistakes (although doubtless I will!) and have to do major cleanup later on code I write now.  I'm trying to understand the environment of x86/UNIX so I get the basics down enough not to hurt myself.

For example if somebody starts out on MVS and doesn't understand how make his code reentrant (and that can be far from trivial) and have its own working storage, it will be painful later to fix. Here it *appears to me* that as far as reentrancy and getting your own working storage goes, that is handled just by the way .data and .bss are implemented and the programmer doesn't have to do anything else in the single threaded case to make sure he doesn't step on himself or anybody else. I understand, especially from Rob's post that in the multithreaded case there are other storage management issues to be dealt with, especially because of the stack.

[Rob Neff]

In both single-threaded and multi-threaded apps your process will not be able to interfere with another process ( provided of course we are talking about 32/64 bit protected mode operating systems here ).  This is by default. Kernel code and certain hardware drivers are obviously the exception to the rule.  Even when using shared objects (Windows .dll / Linux .so) you are still protected from accessing/modifying another process memory space.  You CAN of course call the kernel to set up a shared memory area that can be simultaneous accessed by more than one process.  However, it will be easier once you understand how threading and synchronization is implemented at the single process level.

And if I were learning VMS I'd hope to be able to pick the brains of knowledgeable, friendly, and helpful bunch of guys ( and gals ) too! We just don't like writing other people's programs.  We do, however, critique and guide and maybe even write a few lines for you here and there.   

[JoeCoder]

Thanks again, Rob. BTW I work on MVS, not VMS. I have heard of VMS but I understand it's basically relegated to hobbyist use only nowadays. I had a friend who loved VAX and VMS but he is now a Linux guru while I stayed on MVS since the 1970s and still work on that today. If I can help you or anybody else with that stuff I would be happy to.