[Haskell-cafe] MVar which can not be null ?

15 views
Skip to first unread message

s9gf4ult

unread,
Mar 18, 2013, 3:07:04 AM3/18/13
to haskel...@haskell.org
Hello, I am looking for MVar which can not be null. I need some kind of
thread save atomic IO operation like I can do
with modifyMVar, but I want this variable always contain some value and
never be null.
Thanks.

_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Roman Cheplyaka

unread,
Mar 18, 2013, 3:15:35 AM3/18/13
to s9gf4ult, haskel...@haskell.org
* s9gf4ult <s9gf...@gmail.com> [2013-03-18 13:07:04+0600]
> Hello, I am looking for MVar which can not be null. I need some kind of
> thread save atomic IO operation like I can do
> with modifyMVar, but I want this variable always contain some value and
> never be null.
> Thanks.

Wrap it into a newtype and export only those operations that keep it
non-empty.

Roman

Alexander V Vershilov

unread,
Mar 18, 2013, 3:26:11 AM3/18/13
to s9gf4ult, haskel...@haskell.org
If you have only one variable then you can use:
atomicModifyIORef from IORef it will give you atomic transactions and
IORef will always contains some value.
If you have a list of variables you need to make atomic actions on, then
you may like to use STM.

On 18 March 2013 11:07, s9gf4ult <s9gf...@gmail.com> wrote:
> Hello, I am looking for MVar which can not be null. I need some kind of
> thread save atomic IO operation like I can do
> with modifyMVar, but I want this variable always contain some value and
> never be null.
> Thanks.
>

--
Alexander

s9gf4ult

unread,
Mar 18, 2013, 4:07:42 AM3/18/13
to haskel...@haskell.org
18.03.2013 13:26, Alexander V Vershilov пишет:

I can not use atomicModifyIORef because it works with pure computation

atomicModifyIORef :: IORef a -> (a -> (a, b)) -> IO b

nor STM, becuase IO is not acceptable inside STM transaction.

I just need some thread-safe blocking variable like MVar

modifyMVar :: MVar a -> (a -> IO (a, b)) -> IO b

Edward Z. Yang

unread,
Mar 18, 2013, 4:15:30 AM3/18/13
to s9gf4ult, haskell-cafe
If you are doing IO operations, then the operation is hardly atomic, is it?

Just take from the MVar, compute, and when you're done, put a value
back on the MVar. So long as you can guarantee all users of the MVar
take before putting, you will have the desired semantics.

Something worth considering: what are the desired semantics if an
asynchronous exception is thrown on the thread servicing the MVar?
If the answer is to just quit, what if it has already performed
externally visible IO actions? If the answer is to ignore it, what
if the thread gets wedged?

Edward

Excerpts from s9gf4ult's message of Mon Mar 18 01:07:42 -0700 2013:
> 18.03.2013 13:26, Alexander V Vershilov ?????:
>
> I can not use atomicModifyIORef because it works with pure computation
>
> atomicModifyIORef :: IORef
> <http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-IORef.html#t:IORef>
> a -> (a -> (a, b)) -> IO
> <http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-IO.html#t:IO>
> b
>
> nor STM, becuase IO is not acceptable inside STM transaction.
>
> I just need some thread-safe blocking variable like MVar
>
> modifyMVar :: MVar
> <http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Control-Concurrent-MVar.html#t:MVar>
> a -> (a -> IO
> <http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/System-IO.html#t:IO>
> (a, b)) -> IO
> <http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/System-IO.html#t:IO>
> b

Tim Docker

unread,
Mar 18, 2013, 5:15:02 AM3/18/13
to haskel...@haskell.org
On 18/03/13 19:07, s9gf4ult wrote:

nor STM, becuase IO is not acceptable inside STM transaction.

I just need some thread-safe blocking variable like MVar

modifyMVar :: MVar a -> (a -> IO (a, b)) -> IO b


Whilst it's true that IO cannot be performed within an STM action, a common pattern is to return the necessary IO action from the STM action, and then run it once the STM transaction has completed successfully.

Tim
Reply all
Reply to author
Forward
0 new messages