Re: semaphore question


Josef Moellers wrote:

David Schwartz wrote:

Josef Moellers wrote:

You protect neither files nor global data.

Mutexes protect data.

Yes and no.

Mutexes serialize execution of critical sections.
What you do inside these critical sections is up to you.
You might modify global data, you might modify the internal state of a
device in multiple steps, ...

It is only when you modify data that might be accessed or modified
elsewhere that you need a critical section. (Data being loosely defined
to include things like the state of a device or communications
channel.)

I think this is a very bad way to think about mutexes. Mutexes are
associated with the objects they protect, not the code that accesses
them. Code should not acquire a mutex that protects that code but a
mutex that protects the object that code manipulates.

That is a specific mutex.
Generally speaking (and that was what I was referring to), a mutex is a
semaphore initialized with 1.

Huh? What other kind of mutex is there? Whether it's a mutex, critical
section, semaphore, or whatever, its point is to prevent concurrent
access to the same "thing", whether by the same code or different code.
That "thing" is not code. It is data or state.

Thinking about mutexes as protecting code leads to people putting
mutexes around code that has no need to be protected. Only shared data
(or resources of some kind) requires protection.

Any global state that might be modified concurrently requires protection.

Right, the *state* needs protection.

Code never needs to be protected. Concurrent accesses of the same code
is totally safe and permitted.

It depends on what the code does.

Right, if the code accesses something that needs to be protected, then
that thing needs to be protected.

But I guess I'm thinking of a generic mutex (1-Semaphore) and you're
thinking of a specific use of a mutex.

How would you use a mutex or semaphore to protect something other than
shared state of some kind? Shared state has nothing to do with the
particular code that accesses it, for example, the same protection is
required whether the state is accessed by the same code or different
code in multiple threads.

It is extremely bad practice and does in fact lead to misunderstandings
and bad code to think about synchronization mechanisms of any kind as
protecting code. Synchronization mechanisms protect the things that
more than one thread might want to access or modify, and that is not
code.

Concurrent access to code is perfectly safe so long as there isn't
conflicting access to the same data.

It is impossible to create a problem with conflicting code unless there
is also conflicting data.

If there's conflicting data, there will be a problem whether or not
there's concurrent use of the same code.

DS

.

Relevant Pages

  • Re: help w/ mutex
    ... Not sure I follow your code exactly, but a single thread can acquire a mutex *recursively* What they are designed to ... protect against is multiple threads accessing some resource at the same time. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: sysctl locking
    ... > 2) Extend the simple sysctl handler to use this mutex to protect the actual ... We must not hold the mutex during the useland copy in/out so ... This might need some extension for complex handler (i.e. ... If a sysctl needs that level of protection, it seems like they need to ...
    (freebsd-current)
  • Re: sysctl locking
    ... > 2) Extend the simple sysctl handler to use this mutex to protect the actual ... We must not hold the mutex during the useland copy in/out so ... This might need some extension for complex handler (i.e. ... If a sysctl needs that level of protection, it seems like they need to ...
    (freebsd-arch)
  • RE: Thread.Monitor & references
    ... you can either use lock block or Mutex itself ... > Monitor indicates this would not protect my object. ... since I have no other pointers to this thing. ... > So currently I am using a Mutex to protect this kind of data, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Rich Text Content Control - how to lock down editing
    ... You need to enable document protection to prevent users from making changes, ... such as modifying the properties of a content control. ... Mark those areas that users can modify ... Then you can protect the document with a password. ...
    (microsoft.public.word.docmanagement)