execution context for threads

[Tony Johansson]

Hi!

At the end is some text from e-learning that I use.
Sequrity is one part of the execution context. There is one row in the text
that I find hard to understand and that is this row
"For instance, a method that accesses a file may require a different context
than the one that made a call to it if the security context of the caller
does not provide access to the file"
What does this mean ?


Threads are executed under a given execution context. The execution context
contains information about the security, transaction, synchronization, and
localization contexts of the thread. When calling a method asynchronously,
the method can be executed in a different context because it is a different
thread. For instance, a method that accesses a file may require a different
context than the one that made a call to it if the security context of the
caller does not provide access to the file. In some situations, you may want
to propagate the execution context from one thread to another. In the .NET
Framework, you can achieve this by using the ExecutionContext class.

//Tony

 

[Peter Duniho]

Hi!

At the end is some text from e-learning that I use.
Sequrity is one part of the execution context. There is one row in the text
that I find hard to understand and that is this row
"For instance, a method that accesses a file may require a different context
than the one that made a call to it if the security context of the caller
does not provide access to the file"
What does this mean ? [...]

They are trying to describe a scenario in which your main program has
sufficient privileges to perform an operation (e.g. access a file), but
it for some reason invokes a method asynchronously
(Delegate.BeginInvoke(), or perhaps an i/o class with asynchronous
callback, or even some remoting thing…take your pick) in a way that
causes the actual method execution to take place not only in a different
thread from the one in your main program that does have access (which is
not all that unusual), but also where that other thread for whatever
reason does _not_ have access.

The paragraph is saying that in such a scenario, you can use the
ExecutionContext class to capture the state in the original calling
context, and then use it in your asynchronously-invoked method. This is
done by capturing the current context, creating a copy, and then using
the Run() method with the copy and a delegate representing the entry
point of the code you want to use that copied context to actually
execute the code.

Of course, that means you have to deliver the ExecutionContext object to
the asynchronous method somehow, but that's not any different from
having to deliver other important data. It could be as simple as
something like this:

void MethodInTrustedThread()
{
ExecutionContext context = ExecutionContext.Capture().CreateCopy();

InvokeInUntrustedThread(delegate()
{
// This anonymous method is being executed in some
// context without the same access rights that the
// caller of InvokeInUntrustedThread had.

// You can get around that by executing code like this:
ExecutionContext.Run(context, (obj) =>
{
// Ignore the "obj" state parameter, which we just
// passed "null" for in our call to ExecutionContext.Run()
// and just call whatever code we want here:
MethodInUntrustedThread();
}, null);
});
}

void MethodInUntrustedThread()
{
// even though this is executed in an untrusted thread,
// the ExecutionContext.Run() method ensures that the context
// from the original caller is copied and used, allowing this
// method the same access rights as the original caller.
}

The "InvokeInUntrustedThread()" method above is just a placeholder for
whatever actual method one might call that would cause your callback
method to be executed in a context different from the original one.

Hope that helps.

Pete

 

[Arne Vajhøj]

At the end is some text from e-learning that I use.
Sequrity is one part of the execution context. There is one row in the text
that I find hard to understand and that is this row
"For instance, a method that accesses a file may require a different context
than the one that made a call to it if the security context of the caller
does not provide access to the file"
What does this mean ?

Threads are executed under a given execution context. The execution context
contains information about the security, transaction, synchronization, and
localization contexts of the thread. When calling a method asynchronously,
the method can be executed in a different context because it is a different
thread. For instance, a method that accesses a file may require a different
context than the one that made a call to it if the security context of the
caller does not provide access to the file. In some situations, you may want
to propagate the execution context from one thread to another. In the .NET
Framework, you can achieve this by using the ExecutionContext class.

The text seems clear to me.

Each thread has this context and you could have two threads within
the same thread using different contexts.

I don't think it is something that you should spend much time
experimenting with.

Google would only give me a few examples of its usage:

http://danielvl.blogspot.com/2004/10/executioncontext-class-in-net.html
http://blogs.msdn.com/microsoft_pre...ter-excerpt-from-clr-via-c-third-edition.aspx

Arne

 

[Tony Johansson]

Hi!

At the end is some text from e-learning that I use.
Sequrity is one part of the execution context. There is one row in the
text that I find hard to understand and that is this row
"For instance, a method that accesses a file may require a different
context than the one that made a call to it if the security context of
the caller does not provide access to the file"
What does this mean ? [...]

They are trying to describe a scenario in which your main program has
sufficient privileges to perform an operation (e.g. access a file), but it
for some reason invokes a method asynchronously (Delegate.BeginInvoke(),
or perhaps an i/o class with asynchronous callback, or even some remoting
thing…take your pick) in a way that causes the actual method execution to
take place not only in a different thread from the one in your main
program that does have access (which is not all that unusual), but also
where that other thread for whatever reason does _not_ have access.


Hope that helps.

Pete

Can you give a simple example that show how the main thread have access to a
file but the method that is called asynchronously has not ?
I mean I don't really understand how the main thread making the
asynchronously call have for example file access rights and not the method
being called asynchronously .

//Tony

 

[Peter Duniho]

Can you give a simple example that show how the main thread have access to a
file but the method that is called asynchronously has not ?

It's not something I think about much so you're probably better off
looking for an example provided by someone with more experience in the area.

I mean I don't really understand how the main thread making the
asynchronously call have for example file access rights and not the method
being called asynchronously .

It's definitely not something that would come up if you're just writing
plain vanilla standalone .NET applications. In those kinds of programs,
one would usually just use whatever rights existed when the program
started, and if some kind of failure occurred, suggest to the user to
run the program with more rights.

If I had to create an example, the first thing I'd try would be to use
the user elevation stuff. Do something in the program that requires
admin rights. Perhaps something as simple as opening a file with write
access from an area of the file system that only the admin has write
access for. In such a program, create a new thread that you can use to
execute a method, then in your main thread get the elevated rights
needed to access the file (making sure, of course, to run the program
without admin rights to start with).

Then, create the copied ExecutionContext and pass that to the other
thread, and have it use it to run code that attempts to open the file
with write access.

I know the above description is a bit vague. I'm not elaborating much,
because I'm not even 100% sure that's the scenario in which this is
needed/will work. But it's what I'd try if I were trying to build such
an example. So you might as well try it yourself.

Note that in general, this is the kind of thing that if it were really
useful to you, you'd already know the scenario in which it's useful.
Conversely, if you don't know why it's useful, you don't need to know
how to use it. It's probably sufficient just to know it can be done, in
case you run into something in the future where you do need to know how
to do it.

Pete

 

[Tony Johansson]

It's not something I think about much so you're probably better off
looking for an example provided by someone with more experience in the
area.


It's definitely not something that would come up if you're just writing
plain vanilla standalone .NET applications. In those kinds of programs,
one would usually just use whatever rights existed when the program
started, and if some kind of failure occurred, suggest to the user to run
the program with more rights.

If I had to create an example, the first thing I'd try would be to use the
user elevation stuff. Do something in the program that requires admin
rights. Perhaps something as simple as opening a file with write access
from an area of the file system that only the admin has write access for.
In such a program, create a new thread that you can use to execute a
method, then in your main thread get the elevated rights needed to access
the file (making sure, of course, to run the program without admin rights
to start with).

Then, create the copied ExecutionContext and pass that to the other
thread, and have it use it to run code that attempts to open the file with
write access.

I know the above description is a bit vague. I'm not elaborating much,
because I'm not even 100% sure that's the scenario in which this is
needed/will work. But it's what I'd try if I were trying to build such an
example. So you might as well try it yourself.

Note that in general, this is the kind of thing that if it were really
useful to you, you'd already know the scenario in which it's useful.
Conversely, if you don't know why it's useful, you don't need to know how
to use it. It's probably sufficient just to know it can be done, in case
you run into something in the future where you do need to know how to do
it.

Pete

Good explained peter!!

//Tony

 

[Arne Vajhøj]

Can you give a simple example that show how the main thread have access to a
file but the method that is called asynchronously has not ?
I mean I don't really understand how the main thread making the
asynchronously call have for example file access rights and not the method
being called asynchronously .

There were an example in one of the links I posted.

Arne